I'm trying to run an exe in the background by providing a config file (yml in my case)
Tried the below, however this is not pushing the execution to background. -
./my.exe start --config-file $my_config_file
Found 'start-process' command which are specifically used for this case. With argument list is there any way to send the config file?
Start-Process -Wait -FilePath "my.exe" -ArgumentList
Remove the -Wait argument and pass the process arguments as an array via -ArgumentList parameter:
Start-Process -FilePath "my.exe" -ArgumentList 'start', '--config-file', "`"$my_config_file`""
The strange quoting for $my_config_file is required because a path may contain spaces. Start-Process does not do automatic quoting. From the docs:
If parameters or parameter values contain a space, they need to be surrounded with escaped double quotes.
Note that you won't receive output of the started process, if that matters to you. You can redirect to a file, using parameters -RedirectStandardOutput and -RedirectStandardError, but you can't (easily) store the output in a variable.
A way to start a process in the background, while being able to receive its output, is to create a job.
Related
Here is the program. I am using dell command | configure. The command-line command is as follows:
"C:\Program Files (x86)\Dell\Command Configure\X86_64>cctk.exe" --wakeonlan
In Powershell you can navigate to the folder and run:
./cctk.exe --wakeonlan
I can pipe the above command into a variable and get the information I need. This requires my shell to cd into the folder accordingly and run accordingly.
$test = ./cctk.exe --wakeonlan
This will give you an output. However when you use start-process, you get no output as this is a command-line command. A cmd screen appears and runs the command. So, I added a -nonewwindow and -wait flags. The output now appears on the screen, but I can't seem to capture it.
$test = start-process "C:\Program Files (x86)\Dell\Command Configure\X86_64\cctk.exe" -ArgumentList #("--wakeonlan") -NoNewWindow -Wait
At this point test is empty. I tried using the Out-File to capture the information as well. No success. The command outputs to the screen but nowhere else.
I also tried the cmd method where you pipe the information in using the /C flag.
$test = Start-Process cmd -ArgumentList '/C start "C:\Program Files (x86)\Dell\Command Configure\X86_64\cctk.exe" "--wakeonlan"' -NoNewWindow -Wait
However, I have tried many variations of this command with no luck. Some say C:\Program is not recognized. Some just open command prompt. The above says --wakeonlan is an unknown command.
Any pointers would help greatly.
There are various ways to run this without the added complication of start-process.
Add to the path temporarily:
$env:path += ';C:\Program Files (x86)\Dell\Command Configure\X86_64;'
cctk
Call operator:
& 'C:\Program Files (x86)\Dell\Command Configure\X86_64\cctk'
Backquote all spaces and parentheses:
C:\Program` Files` `(x86`)\Dell\Command` Configure\X86_64\cctk
To elaborate on js2010's helpful answer:
In short: Because your executable path is quoted, direct invocation requires use of &, the call operator, for syntactic reasons - see this answer for details.
To synchronously execute console applications or batch files and capture their output, call them directly ($output = c:\path\to\some.exe ... or $output = & $exePath ...), do not use Start-Process (or the System.Diagnostics.Process API it is based on) - see this answer for more information.
If you do use Start-Process, which may be necessary in special situations, such as needing to run with a different user identity:
The only way to capture output is in text files, via the -RedirectStandardOutput / -RedirectStandardError parameters. Note that the character encoding of the output files is determined by the encoding stored in [Console]::OutputEncoding[1], which reflects the current console output code page, which defaults to the system's active legacy OEM code page.
By contrast, even with -NoNewWindow -Wait, directly capturing output with $output = ... does not work, because the launched process writes directly to the console, bypassing PowerShell's success output stream, which is the one variable assignments capture.
[1] PowerShell uses the same encoding to decode output from external programs in direct invocations - see this answer for details.
I think my problem has a simple solution. But now i'm a bit confused.
I have Java Code, that starts 1 Powershell Script. This Powershell Script must start other scripts.
Java -> Powershell.ps1 ->
Script1.ps1
Script2.ps1
Script3.ps1
Script....
Script1,2,..etc performing multiple tasks and return String Values.
I've tried
Start-Process, Invoke-Command and Invoke-Expression
Assuming script1.ps1 is:
$a = 1+2
$a
Start-Process would work the best for me but im not getting the output:
$arguments = "C:\..\script1.ps1" + " -ClientName" + $DeviceName
$output = Start-Process powershell -ArgumentList $arguments -Credential $credentials
$output
$output ist NULL.
Thank you very much!
Start-Process produces no output by default.
(The only way to make it produce output directly is to use -PassThru, which then doesn't return the script's output, but a System.Diagnostics.Process instance representing the newly created process - see below.)
The only way to capture output from your script via Start-Process is to use the -RedirectStandardOutput and
-RedirectStandardError parameters to capture the script's output as text, in files.[1][2]
You can then read those files in PowerShell after the new process has completed, which you can ensure in one of two ways:
Also pass the -Wait switch to Start-Process, to make the invocation synchronous, which means that when Start-Process returns, the output has already been captured in the specified file(s).
Use -PassThru to obtain a System.Diagnostics.Process instance and pass it to Wait-Process later (or use its .WaitForExit() method directly; property .HasExited can be used to check whether the process is still running).
Here's what may work in your situation:
$arguments = "-File C:\...\script1.ps1" + " -ClientName" + $DeviceName
# Launch the script in a new window running as the given user,
# capture its standard output in file ./out.txt,
# and wait for it to finish.
Start-Process -Wait -RedirectStandardOutput ./out.txt powershell -ArgumentList $arguments -Credential $credentials
"Running script1.ps1 produced the following output:"
Get-Content ./out.txt
The PowerShell CLI, regrettably, reports all of PowerShell's 6 output streams, via standard output (see this answer), so the above captures all output from your script, including error output.
However, you can use, e.g., -RedirectStandardError ./err.txt to capture the error stream separately.
[1] Calling another PowerShell instance via its CLI offers a structured alternative to capturing unstructured text (the for-display output as it would print to the console, which is what happens by default):
-OutputFormat xml (or -of xml / -o xml) makes PowerShell format its output in CLIXML format, which is the same XML-based serialization format used in PowerShell remoting and background jobs for serializing rich objects, which you can "rehydrate" with a later Import-Clixml call.
Note: For most complex objects there is a loss of type fidelity: that is, they are serialized as emulations of the original objects; in short as "property bags" without methods, which, however may be sufficient - see this answer.
Here's a quick demonstration, using a [datetime] instance, which does deserialize with type fidelity:
# Call Get-Date via the PowerShell CLI and save the output
# in CLIXML format in file ./out.xml
Start-Process -Wait -RedirectStandardOutput ./out.xml powershell '-of xml -c Get-Date'
# Import the CLIXML file and convert its content back to a [datetime] instance.
"Type of the CLIXML-serialized and deserialized `Get-Date` output:"
(Import-CliXml ./out.xml).GetType().FullName # -> System.DateTime
[2] The character encoding of the output files is determined by the encoding stored in [Console]::OutputEncoding, which reflects the current console output code page, which defaults to the system's active legacy OEM code page.
I was struggling to get this simple (?) function working today.
I have a PowerShell script that reads computer names from a txt-based file. It works fine when run from a PowerShell session by the following one-liner:
./"Server Health Check.ps1" -List One-off.txt
As you can see, it's got a long file name, so it's wrapped with quotes.
However, I'm building a PowerShell GUI form with radio boxes that will pass on a choice for a text file that will be used to a call the script. Trick is, the script needs to be run with alternate admin account, and i'm not clear how to make that work.
For another script I've got that doesn't use I know i can use something along the lines of the following, this uses the old DOS "runas", however, it doesn't work with the -list function.
invoke-command -scriptblock {runas.exe /user:domain\$Env:Username"admin" "powershell.exe -file \"\\Server\c$\LONG FOLDER\Server Health Check.PS1""}
So, in a nutshell, how do get a script to launch with alternate credentials that reads a parameter (-List) from the command line? I'm also keen to preserve my directory structure, which includes folders with spaces. The script is titled: "Server health check.ps1"
The last thing I tried was the following
$ScriptPath = "C:\SCRIPTS FOLDER\Server Health Check.ps1"
$ArgList = "-List C:\SCRIPTS FOLDER\One-off.txt"
Invoke-Command -filepath $ScriptPath -Credential DragonBallDomain\$Env:UserName"Admin" -ArgumentList $ArgList
The result was the following message:
Invoke-Command : Parameter set cannot be resolved using the specified named parameters.
I'm almost certain this is do-able by invoke-command or start-process, it's just a matter of getting the correct formatting? I'm probably missing a / or a ' or "" somewhere in my trials with start-process or invoke-command.
Any help appreciated!
Update for April 30:
I've tried some more to make this work, i'm close, but still not quite there.
$LongScriptPath = resolve-path Script.ps1
$LongFolderPath = \\UNC\PATH TO FOLDER\WITH LONG NAME\
start-process -filepath powershell.exe -argumentlist " -file``"$($FilePath.path)`"" -cred DOMAIN\USERID -WorkingDirectory "$LongFolderPath"
Adding the -credential is what causes an error that states that the -file parameter is invalid. I'm sure there's a way to do this.
Note: Completely rewritten after the requirements became clearer.
To run a command as a different user locally, use Start-Process -Credential ...
That is what you've attempted in your update in principle, but there are problems with how you're passing parameters; try this instead:
$LongScriptPath = resolve-path Script.ps1
$LongFolderPath = '\\UNC\PATH TO FOLDER\WITH LONG NAME\'
start-process `
powershell.exe `
-ArgumentList '-file', $LongScriptPath, '-List', 'One-off.txt' `
-Credential DOMAIN\USERID `
-WorkingDirectory $LongFolderPath
The key to making this work is to pass all parameters to pass to powershell.exe as an array via Start-Process's -ArgumentList parameter, which means that the parameters must be ,-separated.
Note how an array is always parsed in expression mode, which means that literal string elements such as -file and -List must be quoted.
It is important in general to understand the difference between PowerShell's two fundamental parsing modes, argument mode and expression mode, and which is applied when - see https://technet.microsoft.com/en-us/library/hh847892.aspx
Add -Wait to wait for the script to finish; Start-Process is asynchronous by default (all PS cmdlets named Start-* are).
Caveat: For commands invoked as a different user, you can only wait from an elevated prompt.
If it isn't, the command will still execute, but will do so asynchronously, and you'll get an Access denied error message in the current console; in effect, -Wait is ignored.
Only if not running as a different user: Add -NoNewWindow -Wait if you want to run the script in the current console window; Start-Process opens a new window by default for console applications such as powershell.exe and cmd.exe.
If you do run the command as a different user, -NoNewWindow is quietly ignored.
As for the original symptom and why using Invoke-Command to run a command locally as a different user is ill-advised:
Invoke-Command -Credential ... requires that the -ComputerName parameter be specified too.
Run Get-Help Invoke-Command to see all parameter sets that involve the -Credential parameter. The OP's original command had only -Credential, but not -ComputerName, which caused PS to complain that no parameter set could be unambiguously identified.
Once you use -ComputerName, PowerShell remoting is invariably used, even if you specify . - the local computer - as the only computer to target.
Using remoting has two implications:
Remoting is not available by default, and must be configured on the target computer (the local computer, in this case).
Using remoting requires invocation with admin privileges.
In short:
While you can perform purely local invocations with Invoke-Command, you cannot do so as another user, because that invariably involves remoting.
Start-Process, by contrast, solely exists to run commands locally, optionally as a different user.
I want to use PowerShell to connect to a PuTTY "saved session" and then specify a file that contains some batch commands. Using CMD this would look like
d:\putty\psftp 'Saved Session Name' -b d:\location.txt.
I think that the PS equivalent should look like
Start-Process d:\putty\psftp.exe 'Saved Session Name'
(and then a call to pass a 'get' script) i.e. cd Outgoing get <date>.txt
However, I get the following error:
a positional parameter cannot be found that accepts the argument
How can I accomplish this using PowerShell?
All you need is plink:
plink 'Saved Session Name'
You don't necessarily need Start-Process.
What happens when you try to run d:\putty\psftp.exe 'Saved Session Name' -b d:\location.txt from Powershell? The first thing I do is try it exactly like I'd run it from the command line.
The biggest catch is if you have spaces in path names. You might need to use quotes and the call operator (ampersand): &"d:\putty\psftp.exe" 'Saved Session Name' -b "d:\location.txt".
If you do need to use Start-Process, you can do this:
Start-Process -FilePath "d:\putty\psftp.exe" `
-ArgumentList "'Saved Session Name' -b d:\location.txt" -Wait
Or like this:
Start-Process -FilePath "d:\putty\psftp.exe" `
-ArgumentList 'Saved Session Name', '-b', "d:\location.txt" -Wait
Note that the argument list in the first is a single string with every argument in it, and in the second it is an array of strings with one string for every argument. Everything needs to be in the same order that they'd be on the command line, and it's not uncommon for it to be a bit flaky. Usually one method or the other works better, but it depends on the application you're calling. Usually with quotes and spaces in path names because you're going through multiple levels of escaping depending on the program you're calling (noticing a theme?).
I added the -Wait parameter to my code above because, by default, Start-Process continues to the next line without waiting since it actually spawns a separate process. -Wait forces Powershell to, well, wait, which is what people usually want in a non-interactive script.
See Get-Help about_Operators or Get-Help "call operator" for more topics for help with the call operator. See Get-Help Start-Process for help with that.
Adding the below Technet Wiki link which contains various ways to run executables in PowerShell.
PowerShell: Running Executables
Try this:
$Path = "d:\putty\psftp.exe"
$Prm1 = 'Saved Session Name'
$Prm2 = "-b"
$Prm3 = "d:\location.txt"
&$Path $Prm1 $Prm2 $Prm3
I'd like run a .exe which could be in a number of locations.
$runpath = "$servicepackfolder\SQLServer2008SP1-KB968369-IA64-ENU.exe"
Start-Process -FilePath $runpath -arg "/x:.\$buildfolder\PCU"
Or this way, specifying the WorkingDirectory:
Start-Process 'SQLServer2008SP1-KB968369-IA64-ENU.exe' -WorkingDirectory $servicepackfolder -arg "/x:.\$buildfolder\PCU"
But it seems the variables are not being interpreted as strings.
Start-Process : This command cannot be
executed due to the error: The system
cannot find the file specified.
I am in the correct directory and if I take the output from the $runpath variable and substitute it for the variable in the Start-Process call, I get the expected behavior.
Will this work, or am I stuck hardcoding these paths. Trying to automate the slipstream build process for SQL 2008.
I can duplicate the behavior you see if I add -NoNewWindow but if I don't specify that parameter it works as expected for my test case:
start-process sizeof.exe -WorkingDirectory C:\temp -ArgumentList 1
The new window flashes up and goes away but I can see it is running the specified exe from my temp dir.
Better late than never, but I've found a workaround for this when having the same issue, not sure if it is classed as a bug or not -
Powershell doesn't always handle un-escaped backslashes or quotes in the strings that are stored in a variable / created by string processing all that well for -FilePath, so for your line:
$runpath = "$servicepackfolder\SQLServer2008SP1-KB968369-IA64-ENU.exe"
Try the following (or equivalent) before using $runpath:
$cleanpath = $runpath.replace("\","\\").replace('"',"")
The .replace("\","\\").replace('"',"") escapes the slashes and eliminates the quotes that the string handling and passing introduce, which seems to clear this issue (for some cases).
Bit late for you I imagine but hopefully this helps other people googling for this one.