Powershell Command Processing (Passing in Variables) - command-line

I'm creating a Powershell script to deploy some code and part of the process is to call a command-line compression tool called RAR.EXE to back-up some folders.
I'm attempting to dynamically build out the parameters and then have powershell call the command with the variables but I'm running into trouble. It isn't working...
Run the following script and you should see what I'm talking about. The parameters being passed in as a variable are being mangled. If I pass the entire command + parameters in I get the infamous "is not recognized as a cmdlet..." message.
Thanks for any help!
echo "this should succeed"
& cmd /c echo foo
echo "why does this echo out an additional double quote?"
$param = "/c echo foo"
& cmd "$param"
echo "this does the same"
$param = "/c echo foo"
& cmd $param
echo "escaping the slash doesn't work either..."
$param = "`/c echo foo"
& cmd $param
echo "this fails, but why?"
$cmd = "cmd /c echo foo"
&$cmd

The call operator '&' is unnecessary in this case. It is used to invoke a command in a new scope. This is typically used to invoke a command specified by a string or scriptblock. It also has the side benefit that any variables created in say a PowerShell script are discarded after the command finishes and the scope goes away.
However since the cmd is an EXE it executes in a completely different process. FWIW, you get similar output directly from cmd.exe:
> cmd "/c echo foo"
foo"
So the extra quote on the end is a cmd.exe issue. Typically you need to keep the command separate from the parameters when PowerShell is doing the parsing to invoke the command e.g.
45> & { $foo = "foo" }
46> $foo # Note that $foo wasn't found - it went away with the scope
47> . { $foo = "foo" } # dotting executes in the current scope
48> $foo
foo
The notable exception here is that Invoke-Expression behaves like an "evaluate this string" function. Use with care, especially if the user provides the string. Your day could suck if they provided "ri C:\ -r".
In this case, as others have suggested I would pull the /c out of the string $param string and specify it e.g.:
cmd /c $param
Or use Invoke-Expression but use with care. BTW when you are trying to debug issues with sending arguments to EXE from PowerShell, check out the echoargs utility in PowerShell Community Extensions (http://pscx.codeplex.com). It is very handy:
49> $param = "/c echo foo"
50> echoargs $param
Arg 0 is </c echo foo>
This shows that cmd.exe receives "/c echo foo" as a single argument. "/c" should be a separate argument from "echo foo" (the command to execute).

I have had problems with the & call operator in the past when trying to invoke executable type commands like you are trying. Not sure I understand why. Invoke-Expression however, always seems to work in this context:
PS C:\> $cmd = "cmd /c echo foo"
PS C:\> Invoke-expression $cmd
foo

One other way I found to do this was to create an array of arguments for the command line and use that with the apersand & call operator. Something like this:
$exe = "cmd";
[Array]$params = "/c", "echo", "foo";
& $exe $params;
It's worked well for me.
I originally found this technique here:
http://techstumbler.blogspot.com/2009/12/windows-commands-with-arguments-in.html

Your last example if failing because "&" treats the string as one argument, so it is looking for a program named "cmd /c echo foo.exe". :)
This works:
& $cmd $params
As for the double quote issue, it does seem that cmd does not like the quotes around arguments that PowerShell puts. It gets this:
cmd "/c echo foo"
So I think it treats everything after /c as the exact command, so like so:
echo foo"
Some command line programs and funky parsing of the command line (that is why PowerShell takes over this job for functions and cmdlets). In the case of cmd, I would suggest this:
$param = "echo foo"
& cmd /c $param

it's an artifact of using cmd /c, I think. running
$param = "echo foo"
cmd /c $param
works fine. Unless you have a real code example, it's a bit hard to trouble shoot.

Args are treated differently when they are contained in a String:
PS D:\> echo "1 2 3"
1 2 3
PS D:\> echo 1 2 3
1
2
3
The same results occur when you use a variable for the args:
PS D:\> $param = "1 2 3"
PS D:\> echo $param
1 2 3
The SOLUTION is to use an Array:
PS D:\> $param = #(1,2,3)
PS D:\> echo $param
1
2
3

Related

Running PowerShell from another shell with Tee

I'd like to learn to execute a PowerShell command from another shell or language, e.g. Python os.system(). What I want to achieve is the following:
Execute the PowerShell command
Tee the output to both the console and a file
Return the command exit code
I think this gives an idea of what I would like to achieve, assuming to use cmd.exe as the caller environmnet:
powershell -NoProfile -command "& { cat foo.txt | Tee-Object ps-log.txt; exit $LASTEXITCODE }"
echo %errorlevel%
There are some problems here. First, I cannot use quotations in the command, e.g. :
powershell -NoProfile -command "& { cat `"foo bar.txt`" | Tee-Object ps-log.txt; exit $LASTEXITCODE }"
The cat argument seems to be passed unquoted and so cat looks for a 'bar.txt' parameter.
I think $LASTEXITCODE is expanded soon, that is before cat is executed.
& is inconvenient to use, because it does not accept a single command line string including arguments. An alternative to & is iex, however I cannot use it from cmd.exe. In fact:
powershell -NoProfile -command {iex cat foo.txt}
returns:
iex cat foo.txt
From cmd.exe, use the following (-c is short for -Command):
C:\>powershell -NoProfile -c "Get-Content \"foo bar.txt\" | Tee-Object ps-log.txt; exit -not $?"
There's no reason to use & { ... } in a string passed to -Command - just use ... instead.
Escape embedded " chars. as \" (PowerShell (Core) 7+ also accepts "").
Alternatively, as marsze's helpful answer points out, you can use '...' (single-quoting) inside the "..." string passed to -Command / -c, assuming that no string interpolation is required.
Since only PowerShell-native commands are involved in the command (on Windows, cat is simply an alias of Get-Content), $LASTEXITCODE is not set, as it only reflects the exit code of external programs. Instead, the automatic $? variable applies, which is a Boolean that indicates whether any errors were emitted by the commands in the most recently executed pipeline.
Negating this value with -not means that $true is converted to $false and $false to $true, and these values are converted to integers for the outside, with $false mapping to 0 and $true to 1.
Powershell supports single quotes, which saved me in such situations quite a lot of times. The good thing about it: They are unambiguous and easy to read. But mind that variable expansion won't work inside single-quoted strings.
powershell -NoProfile -command "cat 'foo bar.txt' | tee ps-log.txt"
Apart from that, have a look at the useful advice in mklement0's answer.

passing a second parameter in a batch file

I have a file hello.bat with the following code:
echo first: %1 and second: %2 > me.txt
I am trying to call this using powershell. When I pass the first parameter it works well:
start-process hello test
However when i try to pass the second parameter like this:
start-process hello test test2
I get this error:
Start-Process : A positional parameter cannot be found that accepts argument 'test2'
You can just try pass the arguments using a comma like this:
start-process hello test,test2
or
start-process hello "test test2"
If you want to know more you can read the documentation here.
I don't know why you're starting a command line from a command line but I think this should work:
Start-Process -FilePath $env:ComSpec -ArgumentList "/c hello.bat test test2"
Don't you think it's time to replace cmd with Powershell?
You might change your bat file as well:
echo %1 > me.txt
echo %2 >> me.txt

Run MSBuild from PowerShell can't find project file [duplicate]

I've just tested this on PowerShell v1.0. Setup is as follows:
Id CommandLine
-- -----------
1 $msbuild = "C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe"
4 $a = "C:\some\project\or\other\src\Solution.sln /target:Clean /target:Build"
.
This line fails with an unintuitive error message:
Id CommandLine
-- -----------
5 & $msbuild $a
.
This line fails because & expects the first argument to be the command itself.
Id CommandLine
-- -----------
10 & "$msbuild $a"
.
This line works:
Id CommandLine
-- -----------
16 cmd /c "$msbuild $a"
.
Please explain. I'm more interested in why the & syntax isn't working, than an MSBuild-specific workaround.
Ugh.
$collectionOfArgs = #("C:\some\project\or\other\src\Solution.sln",
"/target:Clean", "/target:Build")
& $msbuild $collectionOfArgs
This works. & takes a collection of arguments, so you must split up strings containing multiple arguments into a collection of string arguments.
The issues you are seeing results from PowerShell parsing arguments. In the first example, when PowerShell sees $a it passes it as a single parameter msbuild. We can see this using the echoargs utility from PSCX:.
PS> $a = "C:\some\project\or\other\src\Solution.sln /target:Clean /target:Build"
PS> & echoargs $a
Arg 0 is <C:\some\project\or\other\src\Solution.sln /target:Clean /target:Build>
The second example is even worse because you are telling powershell to invoke "$echoargs $a" as the command name and it isn't a valid command name.
The third line works because CMD.exe gets the expanded form of "$echoargs $a" as a single argument which is parses and executes:
You have a couple of options here. First I do it this way:
PS> & $msbuild C:\some\project\or\other\src\Solution.sln `
/target:Clean /target:Build
The other option is to use Invoke-Expression like so:
PS> Invoke-Expression "$msbuild $a"
In general I try to be very careful with Invoke-Expression particularly if any part of the string that gets invoked is provided by the user.
You can also try using the free Invoke-MsBuild powershell script/module. This essentially gives you an Invoke-MsBuild PowerShell cmdlet that you can call instead of trying to invoke the msbuild.exe manually yourself.
That works well for me:
PS> cmd.exe /c 'C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe' /target:Clean /target:Build 'C:\some\project\or\other\src\Solution.sln'

How do I pass in a string with spaces into PowerShell?

Given:
# test1.ps1
param(
$x = "",
$y = ""
)
&echo $x $y
Used like so:
powershell test.ps1
Outputs:
> <blank line>
But then this goes wrong:
test.ps1 -x "Hello, World!" -y "my friend"
Outputs:
Hello,
my
I was expecting to see:
Hello, World! my friend
Well, this is a cmd.exe problem, but there are some ways to solve it.
Use single quotes
powershell test.ps1 -x 'hello world' -y 'my friend'
Use the -file argument
powershell -file test.ps1 -x "hello world" -y "my friend"
Create a .bat wrapper with the following content
#rem test.bat
#powershell -file test.ps1 %1 %2 %3 %4
And then call it:
test.bat -x "hello world" -y "my friend"
One can use a backtick ` to escape spaces:
PS & C:\Program` Files\\....
A possible solution was in my case to nest the single and the double quotes.
test.ps1 -x '"Hello, World!"' -y '"my friend"'
I had a similar problem but in my case I was trying to run a cmdlet, and the call was being made within a Cake script. In this case the single quotes and -file argument did not work:
powershell Get-AuthenticodeSignature 'filename with spaces.dll'
Resulting error: Get-AuthenticodeSignature : A positional parameter cannot be found that accepts argument 'with'.
I wanted to avoid the batch file if possible.
Solution
What did work was to use a cmd wrapper with /S to unwrap outer quotes:
cmd /S /C "powershell Get-AuthenticodeSignature 'filename with spaces.dll'"

powershell sending multiple parameter to a external command

I am trying to run a external exe from a powershell script.
This exe wants 4 parameters.
I have been trying every combo of invoke-item, invoke-command, & 'C:\program files\mycmd.exe myparam', made a shortcut in C:\ to get rid of the spaces in the path.
I can make it work with one parameter, but not with more. I get various errors.
To sum up, how do you send 4 parameters to an exe?
It's best if shown in longhand. Once you see what's going on, you can shorten it down by just using commas between each argument.
$arg1 = "filename1"
$arg2 = "-someswitch"
$arg3 = "C:\documents and settings\user\desktop\some other file.txt"
$arg4 = "-yetanotherswitch"
$allArgs = #($arg1, $arg2, $arg3, $arg4)
& "C:\Program Files\someapp\somecmd.exe" $allArgs
... shorthand:
& "C:\Program Files\someapp\somecmd.exe" "filename1", "-someswitch", "C:\documents and settings\user\desktop\some other file.txt", "-yetanotherswitch"
In the easy case, passing arguments to a native exe is as simple as using a built-in command:
PS> ipconfig /allcompartments /all
You can run into problems when you specify a full path to an EXE and that path contains spaces. For example if PowerShell sees this:
PS> C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\sn.exe -k .\pubpriv.snk
It interprets the command to be "C:\Program" and "Files\Microsoft" as the first parameter, "SDKs\Windows\v7.0\Bin\sn.exe" as the second parameter, etc. The simple solution is to put the path in a string use the invocation operator & to invoke the command named by the path e.g.:
PS> & 'C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\sn.exe' -k .\pubpriv.snk
The next area we run into problems with is when the arguments are complex and/or use characters that PowerShell interprets specially e.g.:
PS> sqlcmd -v user="John Doe" -Q "select '$(user)' as UserName"
This doesn't work and we can debug this by using a tool from the PowerShell Community Extensions called echoargs.exe which shows you exactly how the native EXE receives the arguments from PowerShell.
PS> echoargs -v user="John Doe" -Q "select '$(user)' as UserName"
The term 'user' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, ...
<snip>
Arg 0 is <-v>
Arg 1 is <user=John Doe>
Arg 2 is <-Q>
Arg 3 is <select '' as UserName>
Note that with Arg3 $(user) is interpreted & evaluated by PowerShell and results in an empty string. You can fix this problem and a good number of similar issues by using single quotes instead of double qoutes unless you really need PowerShell to evaluate a variable e.g.:
PS> echoargs -v user="John Doe" -Q 'select "$(user)" as UserName'
Arg 0 is <-v>
Arg 1 is <user=John Doe>
Arg 2 is <-Q>
Arg 3 is <select $(user) as UserName>
If all else fails, use a here string and Start-Process like so:
PS> Start-Process echoargs -Arg #'
>> -v user="John Doe" -Q "select '$(user)' as UserName"
>> '# -Wait -NoNewWindow
>>
Arg 0 is <-v>
Arg 1 is <user=John Doe>
Arg 2 is <-Q>
Arg 3 is <select '$(user)' as UserName>
Note if you are using PSCX 1.2 you will need to prefix Start-Process like so - Microsoft.PowerShell.Management\Start-Process to use PowerShell's built-in Start-Process cmdlet.