Special characters in batch files are a pain, but I haven't found the right workaround for properly escaping the first two characters of this particular string I'm trying to pass the application.
SET pass=^&AntiBatchfileString
A_Program.exe /pass=%pass%
Things I have tried:
:: Escaping the escape twice, first for ^, second for &.
SET pass=^^^^&AntiBatchfileString
echo %pass%
:: Combining escapes.
SET first=^^
SET second=^^&AntiBatchfileString
SET pass=%first%%second%
echo %pass%
:: Preventing expansion
SET first=^^
SET second=^^&AntiBatchfileString
SET pass=!first!%second%
echo %pass%
:: I got this to print correctly
SET "pass=^&AntiBatchfileString"
echo ^^%pass%
Still when passing the last one it doesn't accept the login, I don't know what the final output is. That got me thinking maybe it was trying to do another expansion when passing the parameter to the application, so I quoted that as well.
SET "pass=^&AntiBatchfileString"
A_Program.exe "/pass=^^%pass%"
It's still not working, I'm not sure what I'm missing at this point.
Supposing you want the string ^&AntiBatchfileString literally, this is the best set syntax, as most special characters (^ & ( ) < > | and also the standard delimiters , ; = SPACE TAB) lose their particular meaning as soon as ther are placed in between "", and the "" themselves do not become part of the variable value:
set "pass=^&AntiBatchfileString"
This works only as long as the command extensions are on, which is the Windows default anyway (type cmd /? and see the /E option).
When expanding (reading) a variable like "%pass%" (with enclosing ""), special characters are still treated literally.
However, as soon as you expand it like %pass% (no ""), they get back their special meaning. So you have the following options:
Use set "pass=^^^&AntiBatchfileString", where ^^ escapes the literal ^ and ^& the literal & when reading like %pass%.
Enable delayed expansion (see set /? about how it works and setlocal /? or cmd /? about how to enable it), where the variable value is expanded (read) at a point of time where parsing of special characters has already been completed.
I prefer the latter approach, because no special escaping is necessary, and it can also deal with " appearing in the string value (even if unsymmetrically present).
By the way, " can also be escaped by ^", as long as this does not appear within unescaped "".
Nevertheless, % signs cannot be escaped like ^% in a batch file, because percent expansion happens before escaping, but you need to double them like %% to get one literal one each, independent whether or not the string is in between "".
Note that on the console, %% does not work.
Finally, literal ! are consumed by the delayed expansion feature when enabled, therefore you need to pay particular attention to those in case, by escaping them like ^!, or also by intelligently toggling delayed expansion (hence to enable it only when it is actually needed and to disable it otherwise, when a literal string is provided, like in a set command line, for instance, when expanding a standard variable like %pass% and when reading a for variable like %%I (batch file) or %I (console), for example). Of course this is also not the ultimate solution, because you need setlocal and endlocal to enable/disable delayed expansion, which are intended to localise environment changes, so any variable changes since the most recent setlocal command are lost as soon as endlocal is executed (there are some tricks for passing a variable value over the endlocal barrier though).
If you want to use % as a string without escaping in a batch file:
Like %20, you can use %%%20.
git clone "https:// abc.com /D%%%220an"
Related
I have a variable with html code (having major, minor symbols)
and I need it to be exported and appended to a txt
set WORD1=^<p^>^<strong^>PROBLEM^</strong^> with something;n^</p^>
I can't echo the variable like this
echo %WORD1%
And I need to export it/append it to a file. I used:
echo %WORD1% >body.txt
But this generates an error as the variable has minor/Major symbol
If I double quote the variable, the exported text is exported with double quotes (and obviusly this is not what i need)
To define the variable, use:
set "WORD1=<p><strong>PROBLEM</strong> with something;n</p>"
To "export" the variable, use:
(
set /P "=%WORD1%"
echo/
) > body.txt < NUL
To define a variable in a safe way you need to enclose the whole assignment expression in quotation marks:
set "WORD1=<p><strong>PROBLEM</strong> with something;n</p>"
This avoids the need of escaping, unless the string itself contains quotation marks on its own.
Note that this syntax only works with command extensions enabled, but this is the default in Command Prompt anyway.
To return/expand an arbitrary string in a safe manner, even when it contains quotation marks on its own, is to use delayed variable expansion:
echo(!WORD1!
To safely write the output to a file, place the redirection expression at the front:
> "body.txt" echo(!WORD1!
You can also do this on one line:
set "WORD1=<p><strong>PROBLEM</strong> with something;n</p>"&&>body.txt cmd/v/cecho.!WORD1!
rem :: Or, without defining a previous variable, if it is not necessary:
>body.txt <nul set/P "=<p><strong>PROBLEM</strong> with something;n</p>"
Please consider the following very simple batch script (the file is named test.cmd):
#echo off
set "var1=%~1"
echo %var1%
The script should be called with one command line parameter, should assign the string which is contained in that parameter to a variable, and should output the variable.
As expected, I get an error message when I call this script with a command line parameter which contains an ampersand (&):
C:\Batch>test "a&b"
a
'b' is not recognized as an internal or external command,
operable program or batch file.
The reason for this has been discussed in some other questions here and elsewhere, for example that one; the usual remedy is to use delayed expansion. So I changed the script accordingly:
#echo off
setLocal enableDelayedExpansion
set "var1=%~1"
echo !var1!
Now it works with the parameter from before:
C:\Batch>test "a&b"
a&b
But there is a new problem. When the command line parameter contains an exclamation mark (!), it will be dropped from the output:
C:\Batch>test a!b
ab
This behavior also has been discussed at several places, for example here; the crucial thing to note is that dropping the exclamation mark happens during the assignment, not during the echo.
Despite a lot of research, I did not find a question here which provided an elegant solution for both problems at once. That is, is there an elegant way to assign a command line parameter to a variable when that parameter contains an ampersand AND an exclamation mark?
It seems that I need the delayed expansion to treat the ampersand correctly, but this destroys the exclamation mark.
The only solution I currently see is to not use delayed expansion and to add code to explicitly quote all ampersands in the input string. This would be so ugly that I seriously think that I am missing something here.
As a side note, the reason for the problem actually seems to be that there (IMHO!) is no way to get the command line parameter in a delayed-expanded fashion. The syntax for the first parameter is %~1, there is no such thing as !~1.
Move the setLocal enableDelayedExpansion after the the set„ that's all.
#echo off
set "var1=%~1"
setLocal enableDelayedExpansion
echo !var1!
I am trying to understand more about how the Windows CMD parser works. I have been reading several posts about the CMD parser, including this one, but I can't seem to figure out why both carets (^) in the following code are stripped when delayed expansion is DISABLED:
#echo off
setlocal disabledelayedexpansion
set $test_var=This is text with escaped delayed expansion syntax - ^^!$var1^^! and ^^!$var2^^!
echo $test_var = %$test_var%
echo.
pause
I expected the result of running the code to produce the following output:
$test_var = This is text with escaped delayed expansion syntax - ^!$var1^! and ^!$var2^!
Instead, ALL carets are removed:
$test_var = This is text with escaped delayed expansion syntax - !$var1! and !$var2!
From reading the post about the parser, it is my understanding that Phase 2 removes special characters, which includes the caret (^) escape character. From my reading it seems that only one (1) caret character should be removed. Why are both carets removed?
Thanks For Your Help!
The key to the answer is the fact that normal (%-)expansion (phase 1) occurs before recognition of special characters (in phase 2) — refer to the accepted answer to: How does the Windows Command Interpreter (CMD.EXE) parse scripts?
The first carets (^) become removed by the command interpreter in the line
set $test_var=This is text with escaped delayed expansion syntax - ^^!$var1^^! and ^^!$var2^^!
when phase 2 is done, so every instance of ^^ becomes one literal ^. You can prove this when you change #echo off to #echo on, so each parsed command line becomes echoed before being executed, or when you place the following command in the next line (thanks to user jeb for the hint):
rem // This displays the actual content of the variable:
set $test_var
In your next line
echo $test_var = %$test_var%
removal of the remaining carets happens, because – as already said – %-expansion (phase 1) happens first, resulting in a command line like
echo $test_var = This is text with escaped delayed expansion syntax - ^!$var1^! and ^!$var2^!
and then phase 2 follows, where the remaining carets are recognised and removed, resulting in this final text
$test_var = This is text with escaped delayed expansion syntax - !$var1! and !$var2!
You can protect the carets (as well as any other special characters) in the set command line when using the quoted syntax, like this:
set "$test_var=This is text with escaped delayed expansion syntax - ^!$var1^! and ^!$var2^!"
So you can save one level of escaping. However, this only works when the command extensions are enabled, but this is the default setting of the command interpreter anyway.
For the echo command line however, you cannot use such a method, because quotation marks became returned too.
I spotted that you used echo. to output an empty line. You should better use echo/ or echo( (refer to the external resource ECHO. FAILS to give text or blank line - Instead use ECHO/ to find out why).
By the way, your displayed text does not match the actual situation, because you have got delayed expansion disabled.
I am trying to use the rem command to place a remark in a command line that contains several commands. Here are some examples to illustrate what I mean:
echo Hello & rem.Comment & echo world!
(echo Hello & rem.Comment) & echo world!
This works perfectly fine, both echo commands in each line are executed as I expect. The . seems to modify the behaviour of the rem command so that it does not treat the remaining line as comment:
Hello
world!
If I placed a SPACE (or any other delimiter TAB, ,, ;, =) instead of the ., the remaining line and therefore the second echo would be ignored (for the second example a More? prompt appears, because the ) is part of the remark and cmd expects a closing ) because of the ():
Hello
I found out that beside ., the following characters work as well: :, /, \, [, ] and +.
What else works is escaped delimiters: ^SPACE, ^TAB, ^,, ^; and ^=.
Nevertheless, is there a secure and reliable way to do that?
I would be very glad about a solution that works for both command prompt and batch-files.
According to this external reference, the familiar syntax echo. for returning a blank line fails under certain circumstances, hence using echo( is recommended as this is the only reliable method.
However, for rem, the ( does not work, everything after rem( is not recognised as a command.
Since I am aware of a weird bug of the rem command in Windows XP (reference this external link: rem %~), I am interested in a solution that applies to Windows Vista, Windows 7 or higher.
The "weird" REM %~ "bug" is not limited to XP. It is present in all modern versions of Windows that use CMD.EXE. After reading your question, I wrote Simon of SS64 a note to give clarification on the issue. REM can also fail if variable var exists, and you have rem %var:=.
So technically, there is no guaranteed safe way to blindly use REM.
But, if you are willing to accept the fatal % expansion risk, most of your listed hacks are safe to use, but only if the line includes at least one additional command via & or &&.
REM. is never safe to use in any situation if there exists a file named REM (without extension).
The folder dividers \ and / always fail if the current folder contains a file named test.bat and you use REM\..\test.bat.
In a similar fashion, REM:\..\test.bat always fails.
Every one of the other hacks can fail stand-alone in a similar situation. For example, REM^[tab]\..\test.bat fails stand-alone, but works if concatenated with another command. This is the only type of situation I've found where +, [, ], or ^[tab] can fail.
There are additional cases where some of the other hacks can fail.
Any character in the set C (^[space], ^,, ^;, ^=) that are valid in file names can fail stand-alone if remC.bat exists. For example, the following fails stand-alone:
rem^ Fails if "rem .bat" exists
Yet they are all safe when concatenated with another command:
echo OK&rem^ This is safe
rem^ This is safe &echo OK
Temporary Update
Some of the above is wrong. Investigations are ongoing at http://www.dostips.com/forum/viewtopic.php?f=3&t=6895&p=44813#p44813.
I believe the following are the simplest forms that are guaranteed to work in all cases (disregarding invalid % expansion)
REM: At least one space (or other token delimiter) must be after :
REM\ At least one space (or other token delimiter) must be after \
REM/ At least one space (or other token delimiter) must be after /
REM^[tab] At lease one space (or other token delimiter) must be after [tab]
But I won't correct the earlier info until the dust has settled
End Temporary Update
My favorite way to use inline comments is to use impossible variables. Only dynamic pseudo variables can contain = in a name, and no variable name can ever contain two =. So I like to use %= Remark goes here =%. The beauty of this form is it can be used pretty much anywhere with impunity, as long as the comment does not contain % or :. It can even be used safely within parenthesized blocks of code.
for %%F in (*) do (
%= Comment within code block =%
%= 2nd comment within code block =%
FINDSTR /B %=Must match beginning of line=% "string" %= Search string =% "%%F" %= File to search =%
)
This variants of REM seems to be a safe way to enable the & sign in the comment part.
REM/
REM\
REM:
Despite of #dbenham's comment, I can't create any file which would iterfere with these REM variants (I tried REM.bat, REM;.bat and so on).
It's always a good idea to add a space after the REM^<char>.
The problem with %~ can't be solved, as the cmd.exe uses multiple parser phases for each line.
And the %~ error is detected in an early phase (percent expansion phase), just before the phase where a REM would be detected.
But at all, I prefere percent comments for inline comments, described by dbenham
EDIT:
I removed the carets from REM^<char> as it's doesn't matter.
Normally a REM remarks the rest of the line, as the batch parser detects the REM keyword in phase2 of the parser and switches to a specialized parser only for REM.
But when a character is appended to REM the keyword will nt be detected in phase2.
If the character is one of \/;,=+( the parser will remove it later and executes a normal REM command.
That's the cause why the command operators &, &&, |, || can be recognized in this case.
Why rem/ | break fails, but (REM/) | break works?
It's because the pipe starts two seperate cmd child processes.
With surrounding parenthesis the command will be parsed the first time in the child process.
But without parenthesis, the parent process has already parsed the REM/ and checks if the file exists (but doesn't execute it).
But when such a file exists then the parser is smart enough to remove the seperator character and detects that REM is an internal command.
This behaviour looks a bit strange.
SET var=%6
IF NOT "%var%"=="" (
#ECHO "ijklkmn"
EXIT
IF %var:~-2,1%==\ SET var=%var:~0,-2%"
)
If %6 is not defined, then #ECHO "ijklkmn" and is not executed.
But why I still get There should be no 1var:~0。 error???
There are a few batch complexities that are causing your problem.
1) Parenthesized blocks are parsed in one pass. Your entire IF block must parse into valid syntax before the IF test is executed.
2) Substring expansion does weird things if the variable is undefined. The parser expands %var: into nothing, leaving the remainder of the substring expression, and the line parsing becomes entirely out of sync.
IF %var:~-2,1%==\ SET var=%var:~0,-2%"
First %var: expands to nothing, leaving IF ~-2,1%==\ SET var=%var:~0,-2%"
Next %==\ SET var=% is expanded into nothing, leaving IF ~-2,1var:~0,-2%"
Finally, the lone % is not paired, so it is stripped.
The final line after expansion is now IF ~-2,1var:~0,-2", which is invalid syntax.
See https://stackoverflow.com/a/7970912/1012053 for a detailed explanation of how % expansion works.
Your code could be "fixed" by 2 very non-intuitive changes: 1) Reverse the order of the comparison, 2) Add escaped quotes around the SET statement, and 3) add some additional text:
if "\"=="%var:~-2,1%" SET ^"var=%var:~0,-2%"^" ignore
If var is undefined, the above expands to:
if "\" == "~-2,1var:~0,-2"" ignore
The important thing is that the parsed syntax is valid. The ignore is needed because an IF statement needs a command after the condition in order for the parser to see it as valid. It would cause an error if executed because ignore is not a valid command. But it will never get executed because the condition is FALSE (also the outer IF condition is also false).
If var is defined, say with a value of "test\", then the line is expanded as you would think:
if "\" == "\" SET "var=test" ignore
The above executes perfectly because of the way the SET assignment is quoted. Anything after the final quote is ignored.
I say the above will "fix" your code, but I believe there are much better ways to completely restructure your code.
Update: Suggestions for restructuring
It looks to me as though you simply want to set a variable to the value of a quoted parameter, and if the last character in the value (not including quote) is \, then remove that character. It looks like you also have some test code inserted to try to diagnose why your code did not work. Ditching the test code, I recommend the following:
set var=%6
set "test=%var:~-2,1%"
if "%test%"=="\" set var=%var:~0,-2%"
I understand how file names and paths must be quoted to preserve spaces. But I don't like to include the quotes in my variable values. I like to strip the enclosing quotes from my parameters and then add them back only when needed. So my code would look like:
set "var=%~6"
set "test=%var:~-1,1%"
if "%test%"=="\" set "var=%var:~0,-1%"
If delayed expansion is enabled, then a simple solution no longer needs a test variable:
set var=%6
setlocal enableDelayedExpansion
if "!var:~-2,1!"=="\" set "var=!var:~0,-2!""
Or if stripping enclosing quotes:
set "var=%~6"
setlocal enableDelayedExpansion
if "!var:~-1,1!"=="\" set "var=!var:~0,-1!"
I would recommend using the Extension ability defined and everything that dbenham said.
#ECHO off
SET "var=%6"
IF NOT DEFINED var (
ECHO "ijklkmn"
EXIT
)
IF "%var:~-2,1%"=="\" SET "var=%var:~0,-2%""