I'm executing a powershell script during an OS deployment task sequence using SCCM. Due to idiosyncrasies with this ecosystem I have to call the script with syntax like this (to the best of my experimentation):
powershell.exe -executionpolicy bypass -file "w:\scripts\script.ps1" -param1 "%param1%" -param2 "%param2%"
This works fine, but I wanted to capture the output of this and any error messages it throws. Normally I would do something like:
powershell.exe -executionpolicy bypass -file "w:\scripts\script.ps1" -param1 "%param1%" -param2 "%param2%" > "%logfile" 2>&1
However, per the documentation, the -file parameter must be the last parameter, and the above triggers an error since it's trying to interpret the ">" as a parameter.
Obviously I can't use:
powershell.exe -executionpolicy bypass -file "w:\scripts\script.ps1" -param1 "%param1%" -param2 "%param2%" | out-file "%logfile"
because this is a commandline engine, so even if the pipe wasn't interpreted as a parameter, out-file would be interpreted as an executable, not a cmdlet. And even if that worked, out-file doesn't capture the error stream.
Is my only option to output the script's internal logging to a file/transcript, within the script? I feel like there should be a way to do this all from the executable call. The parsing behavior of the -file parameter makes sense, but is obnoxiously limiting.
Thanks,
== Matt
As noted in my comment to the question, this was apparently due to an idiosyncrasy with SCCM's task sequence engine, which somehow causes cmd /c powershell.exe to be interpreted differently than powershell.exe.
Adding the cmd /c solved the issue of > being interpreted as a -file parameter input, rather than as a stream redirection operator.
In fact, I rediscovered that I do use syntax like:
powershell.exe -executionpolicy bypass -file "w:\scripts\script.ps1" -param1 "%param1%" -param2 "%param2%" > "%logfile" 2>&1
successfully outside of the task sequence engine, in other powershell scripts and batch scripts, so it's not a powershell nor commandline interpreter issue.
Related
So I've tried a bunch of different ways to run a PowerShell script from the command line and every single one returns an error.
Here is this path:
C:\Users\test\Documents\test\line space\PS Script\test.ps1
I've tried these:
powershell -File '"C:\Users\test\Documents\test\line space\PS Script\test.ps1"'
powershell "& ""C:\Users\test\Documents\test\line space\PS Script\test.ps1"""
Powershell "& 'C:\Users\test\Documents\test\line space\PS Script\test.ps1'"
Powershell -File 'C:\Users\test\Documents\test\line space\PS Script\test.ps1'"
I get all these errors:
& : The term 'C:\Users\test\Documents\test\line space\PS Script' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Processing -File ''C:\Users\test\Documents\test\line space\PS Script'' failed: The given path's format is not support ed. Specify a valid path for the -File parameter.
How can I fix this?
The -File parameter
If you want to run powershell.exe -File from the command line, you always have to set paths with spaces in double quotes ("). Single quotes (') are only recognized by PowerShell. But as powershell.exe is invoked (and hence the file parameter processed) by the command line, you have to use ".
powershell.exe -File "C:\Users\test\Documents\Test Space\test.ps1" -ExecutionPolicy Bypass
The -Command parameter
If you use the -Command parameter, instead of -File, the -Command content is processed by PowerShell. Hence you can - and in this case have to - use ' inside ".
powershell.exe -Command "& 'C:\Users\test\Documents\Test Space\test.ps1'" -ExecutionPolicy Bypass
The double quotes are processed by the command line, and & 'C:\Users\test\Documents\Test Space\test.ps1' is a command that is actually processed by PowerShell.
Solution 1 is obviously simpler.
Note that -Command is also the default parameter that is used, if you do not specify any.
powershell.exe "& 'C:\Users\test\Documents\Test Space\test.ps1'" -ExecutionPolicy Bypass
This would work, too.
The -EncodedCommand parameter
You can encode your command as Base64. This solves many "quoting" issues and is sometimes (but not in your case though) the only possible way.
First you have to create the encoded command
$Command = "& 'C:\Users\test\Documents\Test Space\test.ps1'"
[Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($Command))
And then you can use the the -EncodedCommand parameter like this
powershell.exe -EncodedCommand JgAgACcAQwA6AFwAVQBzAGUAcgBzAFwAdABlAHMAdABcAEQAbwBjAHUAbQBlAG4AdABzAFwAVABlAHMAdAAgAFMAcABhAGMAZQBcAHQAZQBzAHQALgBwAHMAMQAnAA== -ExecutionPolicy Bypass
Try this:
& "C:\Users\test\Documents\test\line space\PS Script\test"
In your examples, you're mixing quotes and double quoting for no reason.
IF EXIST "C:\Users\test\Documents\test\line space\PS Script\test.ps1" (
powershell -ExecutionPolicy Unrestricted -File "C:\Users\test\Documents\test\line space\PS Script\test.ps1"
)
In case you use parameters you can do as follows.
powershell.exe -command "& {&'C:\A B C\foo.ps1' param1 param2}"
Thanks at this point to a blog post by Hesham A. Amin :-)
I needed to pass a parameter with spaces.
I am dragging and dropping a file onto a batch file, and the file is off on the server with spaces in the path and/or file name. After testing the above answers, I got this to work. Note I am changing to the working directory prior to starting the PowerShell executable.
Batch file:
pushd O:\Data\QuickList
start powershell -noexit -Command ".\QuickList.ps1 -datafile '%1'"
popd
I'm trying to capture the Verbose, Error and other streams of a PowerShell script in a file. This to monitor the output of my script.
The following code works fine:
$LogFile = 'S:\ScriptLog.log'
$ScriptFile = 'S:\TestieScript.ps1'
powershell -Command $ScriptFile *>&1 > $LogFile
However, the moment I try to put a space in one of the file paths, it's no longer working. I tried a lot of things, like double quotes, single quotes, .. but no luck.
To illustrate, the following code doesn't work:
$LogFile = 'S:\ScriptLog.log'
$ScriptFile = 'S:\Testie Script.ps1'
powershell -Command $ScriptFile *>&1 > $LogFile
One person in this thread has the same issue.
Thank you for your help.
You're trying to run a file whose name contains a space as a command without proper quoting, so you're most likely getting an error like this in your log:
The term 'S:\Testie' is not recognized as the name of a cmdlet, function, script file, or operable program.
Either add proper quoting (and the call operator &, because your path is now a string):
powershell -Command "& '$ScriptFile'" *>&1 > $LogFile
or (better) use the -File parameter, as #CB. already suggested:
powershell -File $ScriptFile *>&1 > $LogFile
which has the additional advantage that the call will return the actual exit code of the script.
Edit: If you want to run the command as a scheduled task you'll need to use something like this:
powershell -Command "& 'S:\Testie Script.ps1' *>&1 > 'S:\ScriptLog.log'; exit $LASTEXITCODE"
because the redirection operators only work inside a PowerShell process.
try using -file parameter:
powershell -file $ScriptFile *>&1 > $LogFile
This is my powershell script test.ps1:
Write-Output $args;
Now suppose I have a batch script that calls this powershell script with all kinds of paths. One of those is c:\:
powershell -executionpolicy Bypass -file test.ps1 "c:\"
The output is:
c:"
Is there any way to quote my arguments such that c:\ would actually be taken and stored as is in the $args[0] variable? I know I can solve this quick'dirty by passing "c:\\", but that's not a real solution.
EDIT: using named parameters in test.ps1 doesn't make any difference:
[CmdletBinding()]
param(
[string]$argument
)
Write-Output $argument;
EDIT2: using a batch file instead works fine.
My test.bat script:
echo %~1
I run it:
test.bat "c:\"
Returns nicely:
c:\
Are you sure this comes form powershell and not from the program which invokes your statement? The backslash is no escape code in powershell.
my test.ps1 is working, when run from ise.
this works for me:
powershell -executionpolicy Bypass -command "test.ps1 -argument 'C:\'"
(end with quote double-quote)
Help file for PowerShell.exe says:
File must be the last parameter in the command, because 'all characters' typed after the file parameter name are "interpreted" as the script file path followed by the script parameters.
You are against Powershell.exe's command line parser, which uses "\" to escape quotes. Do you need quotes? Not in your case:
powershell -file test.ps1 c:\
prints
c:\
Similarly, this works too
powershell -file test.ps1 "c:\ "
c:\
but then your arg has that extra space which you would want to trim. BTW, Single quotes do not help here:
powershell -file test.ps1 'c:\'
'c:\'
If you need the final backlash to be passed to the command, you can use
$ArgWithABackslashTemp = $ArgWithABackslash -replace '\\$','\\'
&$ExePath $ArgWithABackslashTemp
Or, if the exe is smart enough to handle it without the trailing backslash
&$ExePath $ArgWithABackslash.trim('\')
For my tests I am using 'Start > Run' dialog (not the cmd.exe).
This works fine, and I get 9 in log.txt
powershell -Command 4+5 > c:\log.txt
But this does not work:
powershell -EncodedCommand IAA1ACsANwAgAA== > c:\log.txt
So how can I redirect output in this case?
Experimental code:
function Test
{
$cmd = { 5+7 }
$encodedCommand = EncodeCommand $cmd
StartProcess "powershell -Command $cmd > c:\log.txt"
StartProcess "powershell -EncodedCommand $encodedCommand > c:\log2.txt"
}
function StartProcess($commandLine)
{
Invoke-WMIMethod -path win32_process -name create -argumentList $commandLine
}
function EncodeCommand($expression)
{
$commandBytes = [System.Text.Encoding]::Unicode.GetBytes($expression)
[Convert]::ToBase64String($commandBytes)
}
The "Run" dialog doesn't seem like it provides redirection at all. According to this usenet post you only get redirection if you have a console. I wonder if the redirection parameter is being parsed by powershell.exe, which is choosing to redirect if it's not receiving encoded input? Sounds like a question for Raymond Chen.
Anyway, this works, at the expense of spawning an otherwise useless console:
cmd /c powershell -EncodedCommand IAA1ACsANwAgAA== > c:\ps.txt
The difference between those two commands is that the -Command parameter is greedy. It takes everything on the command line after it, while -EncodedCommand is not greedy. What the first command is really doing is:
powershell -Command "4+5 > c:\log.txt"
So the new PowerShell instance is handling the redirection. However, if you use the -EncodedCommand paramter, the new PowerShell instance does not see the redirection because you did not include it in the encoded command. This can be a bad thing if the environment calling PowerShell does not have redirection (like in a scheduled task).
So, as "crb" showed, you need to either encode the redirection into your command, or call PowerShell from an environment that can handle the redirection (like cmd, or another PowerShell instance).
I had to encode command together with redirection.
function Test
{
$cmd = { 5+7 }
$encodedCommand = EncodeCommand "$cmd > 'c:\log2.log'"
StartProcess "powershell -Command $cmd > c:\log.txt"
StartProcess "powershell -EncodedCommand $encodedCommand"
}
So this will write a sum 5+7 into c:\log2.log
powershell -EncodedCommand IAA1ACsANwAgACAAPgAgACcAYwA6AFwAbABvAGcAMgAuAGwAbwBnACcA
P.S.
crb suggested to use "cmd /c". But in this case the encoded script length will be constrained by the command line limitations
On computers running Microsoft Windows
XP or later, the maximum length of the
string that you can use at the command
prompt is 8191 characters. On
computers running Microsoft Windows
2000 or Windows NT 4.0, the maximum
length of the string that you can use
at the command prompt is 2047
characters.
For example; with the old command prompt it would be:
cmd.exe /k mybatchfile.bat
Drop into a cmd instance (or indeed PowerShell itself) and type this:
powershell -?
You'll see that powershell.exe has a "-noexit" parameter which tells it not to exit after executing a "startup command".
When running PowerShell.exe just provide the -NoExit switch like so:
PowerShell -NoExit -File "C:\SomeFolder\SomePowerShellScript.ps1"
PowerShell -NoExit -Command "Write-Host 'This window will stay open.'"
Or if you want to run a file and then run a command and have the window stay open, you can do something like this:
PowerShell -NoExit "& 'C:\SomeFolder\SomePowerShellScript.ps1'; Write-Host 'This window will stay open.'"
The -Command parameter is implied if not provided, and here we use the & to call the PowerShell script, and the ; separates the PowerShell commands.
Also, at the bottom of my blog post I show a quick registry change you can make in order to always have PowerShell remain open after executing a script/command, so that you don't need to always explicitly provide the -NoExit switch all the time.
I am sure that you already figure this out but I just post it
$CreateDate = (Get-Date -format 'yyyy-MM-dd hh-mm-ss')
$RemoteServerName ="server name"
$process = [WMICLASS]"\\$RemoteServerName\ROOT\CIMV2:win32_process"
$result = $process.Create("C:\path to a script\test.bat")
$result | out-file -file "C:\some path \Log-$CreatedDate.txt"