I am struggling to use Psexec inside of a PS script to execute an interactive program.
I have tried this:
PsExec.exe -i \\192.168.100.95 -u Administrador -p Test1234 cmd /c "echo . | powershell notepad" 2> $null
... and it runs perfectly fine. Notepad is launched on a remote machine. Now, when I want to run .exe from Program Files (x86) I get absolutely nothing.
I have tried this variations to run 1.exe located in ProgramFiles(x86):
PsExec.exe -i \\192.168.100.95 -u Administrador -p Test1234 cmd /c "echo . | powershell "${env:ProgramFiles(x86)}\1.exe"" 2> $null
PsExec.exe -i \\192.168.100.95 -u Administrador -p Test1234 cmd /c "echo . | powershell "${env:ProgramFiles(x86)}" + "\1.exe"" 2> $null
However none of them work. Any idea what´s wrong?
Try the following:
psexec cmd /c 'echo . | powershell "& \"${env:ProgramFiles(x86)}\1.exe\"' 2>$null
Note: To better focus on the fundamentals of the solution, I've simplified the psexec command, but the original command should work too.
The entire string passed to cmd /k is single-quoted to prevent PS from interpolating elements up front, notably ${env:ProgramFiles(x86)} whose expansion should be deferred until the command is executed on the target machine.
Note that you normally need a double-quoted string when you pass a command line to cmd /c when invoking from cmd.exe itself. From within PowerShell, however, this is not a requirement: PowerShell first parses the string - whether single- or double-quoted originally - interpolates, if applicable, and then passes the resulting string double-quoted to the external command.
Note the & \"...\" construct in the context of the powershell argument, which ensures that the path with embedded spaces is correctly executed.
Curiously, PS requires " chars. to be escaped as \" when a parameter is passed from the outside world (as opposed to escaping as `" inside the realm of PS).
The command passed to powershell as a whole must be double-quoted, because cmd.exe - in whose context powershell is invoked due to cmd /c - only recognizes double quotes as parameter delimiters and only double quotes protect the enclosed content (mostly) from interpretation.
Why your commands didn't work:
The primary problem was that the executable path that you wanted powershell.exe to invoke ended up containing spaces (C:\Program Files...), causing PowerShell not to recognize the entire path as a single argument. Such a path must be (a) quoted and (b) invoked with &, the call operator.
(In the 2nd attempt, with + ... (string concatenation), you would have had to use & also, and enclose the concatenation in (...)).
For debugging, using cmd /k instead of cmd /c can give you a better sense of how the command is ultimately executed (/k keeps the console window open after execution of the command).
A subtler point is that by using a double-quoted string overall, ${env:ProgramFiles(x86)} was expanded on the source machine rather than on the target machine, where the definition of that environment variable may or may not be the same.
You're putting yourself in Escape Hell by mixing PowerShell, CMD and PsExec. If all you want is run an executable on a remote host, just stick with CMD and PsExec (run the command from CMD too):
PsExec.exe -i \\192.168.100.95 -u Administrador -p Test1234 cmd /c echo. ^| "%ProgramFiles(x86)%\1.exe" 2>nul
That way you just need to escape the pipe (^|) and put the path with spaces in double quotes.
Related
I'm trying to make a script that will do some directory management. The final script will run on Windows and will preferably be written in python. At one point in the script I need to automate the creation of multiple symbolic links between multiple folders. The script itself runs without administrator permissions from a bash terminal (Git Bash). Windows is not in developer mode.
The perfect solution would be to have a list of tuples (link, source) and create the corresponding symbolic links all at once, while having to press "Yes" for administrator rights only once.
I already did some research:
How to create a symlink between directories from inside an elevated cmd: Git Bash shell fails to create symbolic links
mklink /D link source_directory
How to run a command in cmd as an administrator from inside bash: Launch Elevated CMD.exe from Powershell
powershell 'start cmd -v runAs -Args /k, [comma-separated-args]'
How to set the working directory after launching the powershell command as an administrator (Otherwise it launches a terminal from inside C:\Windows\System32\): PowerShell: Run command from script's directory
powershell 'start cmd -v runAs -Args /k, cd, $pwd, "&", [comma-separated-args]'
Let's say I want to create a symbolic link in my current working directory to a relative directory. I tried 2 ways:
When I combine all of the above points and execute the following command from the Git Bash terminal:
powershell 'start cmd -v runAs -Args /k, cd, $pwd, "&", mklink, /D, \"link_to_utils\", \"common\utils\"'
A new terminal opens up (after agreeing for admin rights). But it resulted in a new symlink being created in the root of C:\ .
When I execute this:
powershell 'start cmd -v runAs -Args /k, cd, $pwd
A new terminal opens up (after agreeing for admin rights). I can now run this command:
mklink /D "link_to_utils" "common\utils"
The link is created in the current working directory, as I wanted.
So my questions are:
a) How can I make option 1 work in bash?
b) Why is it actually creating the symlink in C:\?
c) Is there a way to pipe a command into the opened elevated cmd terminal (to make option 2 work)?
Note: I have been trying to find a solution using python and the win32api (pywin32). But that resulted in a bunch of command prompts opening up for each symlink that needs to be created. Also there is barely any documentation regarding pywin32.
Use the following:
powershell 'Start-Process -Verb RunAs cmd /k, " cd `"$PWD`" & mklink /D `"link_to_utils`" `"common\utils`" "'
Since it is PowerShell that interprets that verbatim content of the command line being passed, its syntax rules must be followed, meaning that a "..." (double-quoted) string is required for expansion (string interpolation) of the automatic $PWD variable to occur, and that embedded " characters inside that string must be escaped as `" ("" would work too).
The pass-through command line for cmd.exe is passed as a single string argument, for conceptual clarity.
I'm trying to execute the following command in PowerShell, but I have no idea how to escape the ampersand character which is part of the URL
az rest `
--method GET `
--uri ("https://graph.microsoft.com/v1.0/groups?`$count=true&`$filter=startsWith(displayName,'some+filter+text')&`$select=id,displayName") `
--headers 'Content-Type=application/json'
As the & character is used to start a new command, it breaks the url and want to execute the remainder.
Is there a way to tell powershell not to do that?
Olaf's answer provides an effective solution; let me add an explanation:
The source of the problem is a confluence of two behaviors:
When calling external programs, PowerShell performs on-demand double-quoting of each argument solely based on whether a given argument value contains spaces - otherwise, the argument is passed unquoted - irrespective of whether or not the value was originally quoted in the PowerShell command (e.g., cmd /c echo ab, cmd /c echo 'ab', and cmd /c echo "ab" all result in unquoted ab getting passed as the last token on the command line PowerShell rebuilds behind the scenes to ultimately use for execution).
The Azure az CLI is implemented as a batch file (az.cmd) and when a batch file is called, it is cmd.exe that parses the arguments given; surprisingly - and arguably inappropriately - it parses them as if the command had been submitted from inside a cmd.exe session.
As a result, if an argument is passed from PowerShell to a batch file that (a) contains no spaces, yet (b) contains cmd.exe metacharacters such as &, the call breaks.
A simple demonstration, using a cmd /c echo call as a stand-in for a call to a batch file:
# !! Breaks, because PowerShell (justifiably) passes *unquoted* a&b
# !! when it rebuilds the command line to invoke behind the scenes.
PS> cmd /c echo 'a&b'
a
'b' is not recognized as an internal or external command,
operable program or batch file.
There are three workarounds:
Use embedded "..." quoting:
# OK, but with a CAVEAT:
# Works as of PowerShell 7.2, but arguably *shouldn't*, because
# PowerShell should automatically *escape* the embedded " chars. as ""
PS> cmd /c echo '"a&b"'
"a&b"
# Ditto, using an *expandable* (interpolating) PowerShell string:
PS> cmd /c echo "`"$HOME & Family; can't put a `$ value on that.`""
"C:\Users\jdoe & Family; can't put a $ value on that." # e.g.
Use --%, the stop-parsing token - but see the bottom section of this answer for the limitations of --% and its associated pitfalls.
# OK, but with a CAVEAT:
# Requires "..." quoting, but doesn't recognize *PowerShell* variables,
# also doesn't support single-quoting and line continuation.
PS> cmd /c echo --% "a&b"
"a&b"
Call via cmd /c and pass a single string encompassing the batch-file call and all its arguments, (ultimately) using cmd.exe's syntax.
# OK (remember, cmd /c echo stands for a call to a batch file, such as az.cmd)
# Inside the single string passed to the outer cmd /c call,
# be sure to use "...", as that is the only quoting cmd.exe understands.
PS> cmd /c 'cmd /c echo "a&b"'
"a&b"
# Ditto, using an *expandable* (interpolating) PowerShell string:
PS> cmd /c "cmd /c echo `"$HOME & Family; can't put a `$ value on that.`""
"C:\Users\jdoe & Family; can't put a $ value on that." # e.g.
Taking a step back:
Now, wouldn't it be nice if you didn't have to worry about all these things?
Especially since you may not know or care if a given CLI - such as az - just so happens to be implemented as a batch file?
As a shell, PowerShell should do its best to relay arguments faithfully behind the scenes, and allow the caller to focus exclusively on satisfying only PowerShell's syntax rules:
Unfortunately, PowerShell has to date (PowerShell 7.2) generally done a very poor job in this regard, irrespective of cmd.exe's quirks - see this answer for a summary.
With respect to cmd.exe's (batch-file call) quirks, PowerShell could predictably compensate for them in a future version - but it looks like that isn't going to happen, unfortunately; see GitHub issue #15143.
I don't have access to an Azure tennant right now to test and I actually don't have experiences with the Azure CLI in general but I'd expect this to work:
az rest `
--method GET `
--uri 'https://graph.microsoft.com/v1.0/groups?$count=true&$filter=startsWith(displayName,some+filter+text)&$select=id,displayName' `
--headers 'Content-Type=application/json'
or this:
az rest --method GET --headers "Content-Type=application/json" `
--% --uri "https://graph.microsoft.com/v1.0/groups?$count=true&$filter=startsWith(displayName,some+filter+text)&$select=id,displayName"
I only added the backticks for better readability - you may remove them in your actual code.
If I pass an IF statement through PowerShell's Invoke-Expression, the command appears to be running and completing, but then it appears that the output is being evaluated as a new command instead of being returned to PowerShell. Three examples:
Invoke-Expression 'echo "hi"' (No IF statement)
Normal Output: hi
Invoke-Expression 'cmd /c IF exist C:\Windows (echo "hi")'
Error on Output: 'hi' is not recognized as an internal or external command, operable program or batch file.
Invoke-Expression 'cmd /c IF exist C:\Windows (query user)'
Error on Output:
'" USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME"' is not recognized as an internal or external command, operable program or batch file.
What's the best way to run a command-line IF statement from PowerShell and be able to read its output? I tried Start-Process but cannot figure out for the life of me how to read its output. Tried a System.Diagnostics.ProcessStartInfo object copied from another StackOverflow post, but no luck there either.
Because people are bound to ask: The reason why I'm passing this through cmd in the first place is because this entire code block needs to be passed through Invoke-Command to a remote machine and cmd has folder/file access to computers on its network while PowerShell does not.
Your immediate problem is unrelated to the use of Invoke-Expression, which should generally be avoided:
cmd /c IF exist C:\Windows (echo "hi") # WRONG
is interpreted by PowerShell first, up front, and (echo "hi") is the same as (Write-Output "hi"), which PowerShell expands (interpolates) to the command's output, a string with content hi.
The - broken - command line that cmd exe ends up seeing is the following, which explains the error message:
cmd /c IF exist C:\Windows hi
For an overview of how PowerShell parses unquoted command-line arguments, see this answer.
There are several ways to fix that problem, appropriate in different scenarios:
# Single-quoting - passed as-is.
cmd /c 'IF exist C:\Windows (echo "hi")'
# Double-quoting - PowerShell would still expand $-prefixed tokens up front.
cmd /c "IF exist C:\Windows (echo `"hi`")"
#`# The stop-parsing symbol, --%, prevents PowerShell from parsing subsequent arguments,
# with the exception of cmd-style environment-variable references (%FOO%)
cmd /c --% IF exist C:\Windows (echo "hi")
Now, with Invoke-Expression you'd have to add escape those quotes due to having to specify them as part of a string, but, as mentioned in the comments, there is rarely a need for Invoke-Expression, and it is neither needed here, nor would I expect it to help with the "double hop" authentication problem you describe in a comment.
To address the latter, try this answer, which uses explicitly passed credentials to establish an auxiliary drive mapping on the remote machine.
I have to execute two commands (including a PowerShell one) in new console window. Let me explain:
I am able to execute a PowerShell command from cmd in a new console window (I can specify the command inside quotes):
start /W cmd /K powershell -command "&{Write-Host 'Hello World!';}"
And I can execute two commands (I can write both commands in quotes):
start /W cmd /K "echo Hello && echo World"
But how can I do it together (execute two commands, one of them PowerShell)? I would like to do it without any .bat or .ps script.
I tried something like following (and some variations with escaping character), but I cannot deal with this quotes issue (there are quotes for joining two commands and inside quotes for PowerShell command).
start /W cmd /K "echo Hello && powershell -command "&{Write-Host 'Hello World!';}""
You need to escape & in powershell's ScriptBlock for cmd:
start /W cmd /K "echo Hello && powershell -command "^&{Write-Host 'Hello World!';}""
I need to run a remote command with help of PowerShell from CMD. This is the command I call from CMD:
powershell -command "$encpass=convertto-securestring -asplaintext mypass -force;$cred = New-Object System.Management.Automation.PSCredential -ArgumentList myuser,$encpass; invoke-command -computername "REMOTE_COMPUTER_NAME" -scriptblock {<command>} -credential $cred;"
in place of <command> (including < and > signs) can be any command which can be run in cmd.exe. For example there can be perl -e "print $^O;" or echo "Hello World!" (NOTE: There cannot be perl -e 'print $^O;', because it is incorrect command for CMD due to the single quotes). So it appears the command perl -e "print $^O;" and any other command which contains double quotes doesn't handled as expected. Here I expect it to return OS name of remote box from perl's point of view, but it prints nothing due to obscure handling of double quotes by PowerShell and/or CMD.
So the question is following, how to run command correct for CMD in remote box using PowerShell?
There are several possible problems with the command line in the OP. If the command line in the OP is being executed from Powershell itself the $encpass and $cred will get substituted before the (sub-instance) of powershell is invoked. You need to use single quotes or else escape the $ signs, for example:
powershell -command "`$encpass=2"
powershell -command '$encpass=2'
If, instead of using Powershell, the command line is executed from CMD, then ^ has to be escaped, because it is the CMD escape character.
And quoting " is a good idea as well. In a few tests that I did I had to use unbalanced quotes to get a command to work, for example, from powershell:
powershell -command "`$encpass=`"`"a`"`"`"; write-host `$encpass"
worked, but balanced quotes didn't.
To avoid all this, probably the most robust way to do this is given in powershell command line help: powershell -?:
# To use the -EncodedCommand parameter:
$command = 'dir "c:\program files" '
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)
$encodedCommand = [Convert]::ToBase64String($bytes)
powershell.exe -encodedCommand $encodedCommand
However there is a new feature in PS 3.0 that is also supposed to help, but I don't think it will be as robust. Described here: http://blogs.msdn.com/b/powershell/archive/2012/06/14/new-v3-language-features.aspx, near the middle of the blog.