I used msbuild to build a deployment package for my website. I am trying to use the generated deploy.cmd file located in the package to deploy to a remote server. I am using web deploy's parameters and I would like to set these at the command line using the -setParam flag.
The usage instructions for WebDeploy indicate that I need to enclose the -setParam configuration option in quotation marks because it contains an '=' character. However, the deploy.cmd file passes the entire option, including quotation marks, to the msdeploy executable. The msdeploy executable fails to run because the option does not start with the "-" character.
Error: Unrecognized argument '"-setParam:TestParam=ABC123"'. All arguments must begin with "-".
What do I need to do in order to get the setParam call working with the cmd file generated by msBuild?
Have successfully used -setParam option in the following syntax, enclosing entire option in double quotes, and dubling double quotes inside:
...deploy.cmd "-setParam:name=""IIS Web Application Name"",value=""example.com"""
You don't need to wrap the entire parameter in quotes because of the equals sign. Just the parameter key and value because it may contain spaces.
-setParam:"TestParam"="ABC123"
should work for your example. Or in real world:
-setParam:"IIS Web Application Name"="example.com"
Related
I am testing group migration using ADMT cmd line, but the migration is failing for a specific case when the OU name contains double quotes.
ADMT GROUP /n "TestGroup" /sd:Child.A.COM /sdc.CHILD.A.COM /td.COM /tdc.A.COM /to:"ParentOU/TEST!##$%^&*()_+{}|:"<>?[]\;',./" /intraforest:yes
In cmd this throws "> was unexpected at this time" and in powershell it keeps waiting for more parameters. The main purpose is to convert this to a c# script the migrates the users/groups but it failed in the testing phase with cmd/powershell. Is there any way to make this possible at least in C#?
I have tried escaping the double quotes with "", ^", ", `" but nothing seems to work. I have also tried assigning the value to a variable and using the variable in powershell. Using "" (as suggested in this Escaping special characters in cmd) is the only time the command runs but it still throws the following error.
Error: Unable to migrate groups. Unable to bind to container
'ParentOU/TEST!##$%^&()+{}|:<>?[];',./ /intraforest:yes'. Unable to
get distinguished name for
'A.COM/ParentOU/TEST!##$%^&;()+{}|:<>?[];',./ /intraforest:yes'. :
The parameter is incorrect. (0x80070057)
The same is working if I create another OU with same name except for the double quotes.
Please help in resolving this issue.
You can do solve it in different ways:
With escaping the characters with carets outside of the quote
setlocal EnableDelayedExpansion
set "to_param=ParentOU/TEST^!##$%^&*()_+{}|:"^^^^^<^^^^^>?[];',./"
call ADMT GROUP /to:"%%to_param%%"
The main problem will be the ADMT program, you need to know how it parses the arguments, particularly with regard to the rules how it escape quotes inside arguments.
You could test \" in set "to_param=ParentOU...\"^^^^^<^^^^^>?[];',./"
I know there are lots of posts regarding this, but nothing worked for me.
I am trying to run this command line in PowerShell:
C:/Program Files (x86)/ClamWin/bin/clamd.exe --install
I have this in PowerShell:
&"C:/Program Files (x86)/ClamWin/bin/clamd.exe --install"
But all this does is execute clamd.exe, ignoring the --install parameter
How can I get the full command line to run?
Josef Z's comment on the question provides the solution:
& "C:/Program Files (x86)/ClamWin/bin/clamd.exe" --install # double-quoted exe path
or, given that the executable path is a literal (contains no variable references or subexpressions), using a verbatim (single-quoted) string ('...'):
& 'C:/Program Files (x86)/ClamWin/bin/clamd.exe' --install # single-quoted exe path
As for why your own solution attempt failed: The call operator, &, expects only a command name/path as an argument, not a full command line.
Invoke-Expression accepts an entire command line, but that complicates things further and can be a security risk.
As for why this is the solution:
The need for quoting stands to reason: you need to tell PowerShell that C:/Program Files (x86)/ClamWin/bin/clamd.exe is a single token (path), despite containing embedded spaces.
&, the so-called call operator, is needed, because PowerShell has two fundamental parsing modes:
argument mode, which works like a traditional shell, where the first token is a command name, with subsequent tokens representing the arguments, which only require quoting if they contain shell metacharacters (chars. with special meaning to PowerShell, such as spaces to separate tokens);
that is why --install need not, but can be quoted (PowerShell will simply remove the quotes for you before passing the argument to the target executable.)
expression mode, which works like expressions in programming languages.
PowerShell decides based on a statement's first token what parsing mode to apply:
If the first token is a quoted string - which we need here due to the embedded spaces in the executable path - or a variable reference (e.g., $var ...), PowerShell parses in expression mode by default.
A quoted string or a variable reference as an expression would simply output the string / variable value.
However, given that we want to execute the executable whose path is stored in a quoted string, we need to force argument mode, which is what the & operator ensures.
Generally, it's important to understand that PowerShell performs nontrivial pre-processing of the command line before the target executable is invoked, so what the command line looks like in PowerShell code is generally not directly what the target executable sees.
If you reference a PowerShell variable on the command line and that variable contains embedded spaces, PowerShell will implicitly enclose the variable's value in double quotes before passing it on - this is discussed in this answer to the linked question.
PowerShell's metacharacters differ from that of cmd.exe and are more numerous (notably, , has special meaning in PowerShell (array constructor), but not cmd.exe - see this answer).
To simplify reuse of existing, cmd.exe-based command lines, PowerShell v3 introduced the special stop-parsing symbol, --%, which turns off PowerShell's normal parsing of the remainder of the command line and only interpolates cmd.exe-style environment-variable references (e.g., %USERNAME%).
I would like to open a C:\Program Files\R\R-3.2.0\bin\Rscript.exe. For that I am trying to change the directory. I figured that the error is in opening Program files. Following is the code
cd Program Files\R\R-3.2.0\bin
Error: A positional parameter cannot be found that accepts argument Files
Unlike command.com/cmd.exe, PowerShell follows much more consistent rules and in the failing case Program and Files\R..bin are parsed as two separate arguments, where the second is invalid in context (as cd only accepts a single non-named argument).
To fix this use quotes, eg.
cd "C:\Program Files"
With the quotes it is parsed as a string value which is supplied as a single argument (the string itself does not include the quotes, again unlike cmd.exe rules).
FWIW, cd is an alias for Set-Location. Run get-help cd for the details on how it can be used - include which optional (and named) parameters it does support.
You need to put the path in quotes if it contains a space:
cd 'C:\Program Files\R\R-3.2.0\bin'
Either single or double quotes will work.
I'm trying to put together an SFTP command to be run through Powershell. The executable I have access to is SFTPC.exe (Bitvise Tunnelier)
The command I'm trying is
sftpc.exe user#ftp.domain.com -pw=password -unat=y -cmd="ls \"somefile.txt\""
According to the documentation at https://www.bitvise.com/files/sftpc-v4.14-usage.txt this should log in and run the command ls "somefile.txt" (quotes are escaped within the command parameter)
What actually happens is that I get another line for input, as if there's an unclosed quote.
I've tried adding an extra quote to the end
sftpc.exe user#ftp.domain.com -pw=password -unat=y -cmd="ls \"somefile.txt\"""
This connects and logs in, but the colland it tries to run is ls \somefile.txt"
Note the trailing quote and the leading slash.
So it looks like I'm missing something in the quote escaping, but I can't see what I might be doing wrong. I've also tried replacing double quotes with single in a couple of different places, experiments that usually end in a syntax error.
The escape character in powershell is not a backslash, it's the backtick.
Does the below work?
sftpc.exe user#ftp.domain.com -pw=password -unat=y -cmd="ls `"somefile.txt`""
So I have created a build process template in TFS 2012 that has to pass a path name to a Powershell Script, which in turn concatenates files in the specified directory.
Some of these path names might have two consecutive spaces, which has turned out to be a problem.
When I invoke the powershell script, I enclose the path name in single quotes, and the command that is executed looks something like this.
powershell C:\psScript.ps1 'C:\tmp\two spaces\myFolder'.
However, when I try and open the directory in Powershell, I get the following error:
Get-Item : Cannot find path 'C:\tmp\two spaces\myFolder'
because it does not exist.
The two spaces seem to have become one, and the path can't be found.
Does anyone know what might be causing this?