Batch script interpreting content inside comment?
When I run the following batch script:
@echo off
REM %~ will strip surrounding quotes if any
echo HERE
I get the following error:
C:>test.cmd
The following usage of the path operator in batch-parameter
substitution is invalid: %~ will strip surrounding quotes if any
For valid formats type CALL /? or FOR /?
Same effect if REM
is changed to ::
.
Seems like the parser is ignoring the comment indicator and parsing the %~
. If I put a space between the %
and ~
then it works fine.
Windows 7 Enterprise (have not checked any other versions).
Seems like a bug to me, but am I missing something?
windows batch-file
add a comment |
When I run the following batch script:
@echo off
REM %~ will strip surrounding quotes if any
echo HERE
I get the following error:
C:>test.cmd
The following usage of the path operator in batch-parameter
substitution is invalid: %~ will strip surrounding quotes if any
For valid formats type CALL /? or FOR /?
Same effect if REM
is changed to ::
.
Seems like the parser is ignoring the comment indicator and parsing the %~
. If I put a space between the %
and ~
then it works fine.
Windows 7 Enterprise (have not checked any other versions).
Seems like a bug to me, but am I missing something?
windows batch-file
3
I think that happens in an early parsing phase, for details see how-does-the-windows-command-interpreter-cmd-exe-parse-scripts
– LotPings
Nov 21 '18 at 0:59
Wow! Just when I thought Batch couldn't be more brain dead, I learn about this, and find a new low. Sigh...
– codesniffer
Nov 22 '18 at 1:25
add a comment |
When I run the following batch script:
@echo off
REM %~ will strip surrounding quotes if any
echo HERE
I get the following error:
C:>test.cmd
The following usage of the path operator in batch-parameter
substitution is invalid: %~ will strip surrounding quotes if any
For valid formats type CALL /? or FOR /?
Same effect if REM
is changed to ::
.
Seems like the parser is ignoring the comment indicator and parsing the %~
. If I put a space between the %
and ~
then it works fine.
Windows 7 Enterprise (have not checked any other versions).
Seems like a bug to me, but am I missing something?
windows batch-file
When I run the following batch script:
@echo off
REM %~ will strip surrounding quotes if any
echo HERE
I get the following error:
C:>test.cmd
The following usage of the path operator in batch-parameter
substitution is invalid: %~ will strip surrounding quotes if any
For valid formats type CALL /? or FOR /?
Same effect if REM
is changed to ::
.
Seems like the parser is ignoring the comment indicator and parsing the %~
. If I put a space between the %
and ~
then it works fine.
Windows 7 Enterprise (have not checked any other versions).
Seems like a bug to me, but am I missing something?
windows batch-file
windows batch-file
edited Nov 21 '18 at 8:25
michael_heath
2,8422617
2,8422617
asked Nov 21 '18 at 0:08
codesniffercodesniffer
19911
19911
3
I think that happens in an early parsing phase, for details see how-does-the-windows-command-interpreter-cmd-exe-parse-scripts
– LotPings
Nov 21 '18 at 0:59
Wow! Just when I thought Batch couldn't be more brain dead, I learn about this, and find a new low. Sigh...
– codesniffer
Nov 22 '18 at 1:25
add a comment |
3
I think that happens in an early parsing phase, for details see how-does-the-windows-command-interpreter-cmd-exe-parse-scripts
– LotPings
Nov 21 '18 at 0:59
Wow! Just when I thought Batch couldn't be more brain dead, I learn about this, and find a new low. Sigh...
– codesniffer
Nov 22 '18 at 1:25
3
3
I think that happens in an early parsing phase, for details see how-does-the-windows-command-interpreter-cmd-exe-parse-scripts
– LotPings
Nov 21 '18 at 0:59
I think that happens in an early parsing phase, for details see how-does-the-windows-command-interpreter-cmd-exe-parse-scripts
– LotPings
Nov 21 '18 at 0:59
Wow! Just when I thought Batch couldn't be more brain dead, I learn about this, and find a new low. Sigh...
– codesniffer
Nov 22 '18 at 1:25
Wow! Just when I thought Batch couldn't be more brain dead, I learn about this, and find a new low. Sigh...
– codesniffer
Nov 22 '18 at 1:25
add a comment |
2 Answers
2
active
oldest
votes
The %
-expansion, hence expanding normal environment variables (like %VAR%
) as well as command line arguments (like %0
), is the very first step after having read a line, therefore it happens even before the rem
command is recognised. Thus you need to avoid the %~
(by writing rem % + ~ ...
, for instance).
Given that the command extensions are enabled, which is the default anyway, %~
is recognised as invalid argument syntax (the ~
is expected to be followed by a decimal digit denoting the argument position or by a valid modifier like f
, d
, p
, n
, x
, etc.; see Command Line arguments (Parameters)) and results in a fatal error, meaning that an error message is thrown and batch file processing is aborted (the %ErrorLevel%
is not set though).
The same effect comes up when you try to do sub-string substitution but specifying an empty search string (like %VAR:=replace%
or %VAR:*=replace%
, given that VAR
is defined), also with command extensions enabled.
See also this thread: How does the Windows Command Interpreter (CMD.EXE) parse scripts?
add a comment |
I think it is clearly covered in quite a few docs that cmd will interpret the arguments before comments, see the example in @LotPings comment as well as @aschiphl's post. That being said, you can momentarily disableextensions
and then turn it back on when needed. The below example shows how disabling it will allow you to use it in the REM
comment and then enabled again after to show allow extensions:
@echo off
setlocal disableextensions
REM %~ will strip surrounding quotes if any"
endlocal
echo my batch file is %~0
3
Instead ofsetlocal enableextensions
I would useendlocal
to return to the former state (default) and to the former environment, thus having the same state as in the original code...
– aschipfl
Nov 21 '18 at 9:01
@aschipfl true yes, I think I just wanted to demonstrate enable and disable, but will change.
– Gerhard Barnard
Nov 21 '18 at 9:18
Thanks for the workaround idea! Considering the extra lines to work around this, I simply used a valid expression there: %~1.
– codesniffer
Nov 22 '18 at 1:27
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53403485%2fbatch-script-interpreting-content-inside-comment%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The %
-expansion, hence expanding normal environment variables (like %VAR%
) as well as command line arguments (like %0
), is the very first step after having read a line, therefore it happens even before the rem
command is recognised. Thus you need to avoid the %~
(by writing rem % + ~ ...
, for instance).
Given that the command extensions are enabled, which is the default anyway, %~
is recognised as invalid argument syntax (the ~
is expected to be followed by a decimal digit denoting the argument position or by a valid modifier like f
, d
, p
, n
, x
, etc.; see Command Line arguments (Parameters)) and results in a fatal error, meaning that an error message is thrown and batch file processing is aborted (the %ErrorLevel%
is not set though).
The same effect comes up when you try to do sub-string substitution but specifying an empty search string (like %VAR:=replace%
or %VAR:*=replace%
, given that VAR
is defined), also with command extensions enabled.
See also this thread: How does the Windows Command Interpreter (CMD.EXE) parse scripts?
add a comment |
The %
-expansion, hence expanding normal environment variables (like %VAR%
) as well as command line arguments (like %0
), is the very first step after having read a line, therefore it happens even before the rem
command is recognised. Thus you need to avoid the %~
(by writing rem % + ~ ...
, for instance).
Given that the command extensions are enabled, which is the default anyway, %~
is recognised as invalid argument syntax (the ~
is expected to be followed by a decimal digit denoting the argument position or by a valid modifier like f
, d
, p
, n
, x
, etc.; see Command Line arguments (Parameters)) and results in a fatal error, meaning that an error message is thrown and batch file processing is aborted (the %ErrorLevel%
is not set though).
The same effect comes up when you try to do sub-string substitution but specifying an empty search string (like %VAR:=replace%
or %VAR:*=replace%
, given that VAR
is defined), also with command extensions enabled.
See also this thread: How does the Windows Command Interpreter (CMD.EXE) parse scripts?
add a comment |
The %
-expansion, hence expanding normal environment variables (like %VAR%
) as well as command line arguments (like %0
), is the very first step after having read a line, therefore it happens even before the rem
command is recognised. Thus you need to avoid the %~
(by writing rem % + ~ ...
, for instance).
Given that the command extensions are enabled, which is the default anyway, %~
is recognised as invalid argument syntax (the ~
is expected to be followed by a decimal digit denoting the argument position or by a valid modifier like f
, d
, p
, n
, x
, etc.; see Command Line arguments (Parameters)) and results in a fatal error, meaning that an error message is thrown and batch file processing is aborted (the %ErrorLevel%
is not set though).
The same effect comes up when you try to do sub-string substitution but specifying an empty search string (like %VAR:=replace%
or %VAR:*=replace%
, given that VAR
is defined), also with command extensions enabled.
See also this thread: How does the Windows Command Interpreter (CMD.EXE) parse scripts?
The %
-expansion, hence expanding normal environment variables (like %VAR%
) as well as command line arguments (like %0
), is the very first step after having read a line, therefore it happens even before the rem
command is recognised. Thus you need to avoid the %~
(by writing rem % + ~ ...
, for instance).
Given that the command extensions are enabled, which is the default anyway, %~
is recognised as invalid argument syntax (the ~
is expected to be followed by a decimal digit denoting the argument position or by a valid modifier like f
, d
, p
, n
, x
, etc.; see Command Line arguments (Parameters)) and results in a fatal error, meaning that an error message is thrown and batch file processing is aborted (the %ErrorLevel%
is not set though).
The same effect comes up when you try to do sub-string substitution but specifying an empty search string (like %VAR:=replace%
or %VAR:*=replace%
, given that VAR
is defined), also with command extensions enabled.
See also this thread: How does the Windows Command Interpreter (CMD.EXE) parse scripts?
edited Nov 21 '18 at 9:07
answered Nov 21 '18 at 1:54
aschipflaschipfl
18.9k92856
18.9k92856
add a comment |
add a comment |
I think it is clearly covered in quite a few docs that cmd will interpret the arguments before comments, see the example in @LotPings comment as well as @aschiphl's post. That being said, you can momentarily disableextensions
and then turn it back on when needed. The below example shows how disabling it will allow you to use it in the REM
comment and then enabled again after to show allow extensions:
@echo off
setlocal disableextensions
REM %~ will strip surrounding quotes if any"
endlocal
echo my batch file is %~0
3
Instead ofsetlocal enableextensions
I would useendlocal
to return to the former state (default) and to the former environment, thus having the same state as in the original code...
– aschipfl
Nov 21 '18 at 9:01
@aschipfl true yes, I think I just wanted to demonstrate enable and disable, but will change.
– Gerhard Barnard
Nov 21 '18 at 9:18
Thanks for the workaround idea! Considering the extra lines to work around this, I simply used a valid expression there: %~1.
– codesniffer
Nov 22 '18 at 1:27
add a comment |
I think it is clearly covered in quite a few docs that cmd will interpret the arguments before comments, see the example in @LotPings comment as well as @aschiphl's post. That being said, you can momentarily disableextensions
and then turn it back on when needed. The below example shows how disabling it will allow you to use it in the REM
comment and then enabled again after to show allow extensions:
@echo off
setlocal disableextensions
REM %~ will strip surrounding quotes if any"
endlocal
echo my batch file is %~0
3
Instead ofsetlocal enableextensions
I would useendlocal
to return to the former state (default) and to the former environment, thus having the same state as in the original code...
– aschipfl
Nov 21 '18 at 9:01
@aschipfl true yes, I think I just wanted to demonstrate enable and disable, but will change.
– Gerhard Barnard
Nov 21 '18 at 9:18
Thanks for the workaround idea! Considering the extra lines to work around this, I simply used a valid expression there: %~1.
– codesniffer
Nov 22 '18 at 1:27
add a comment |
I think it is clearly covered in quite a few docs that cmd will interpret the arguments before comments, see the example in @LotPings comment as well as @aschiphl's post. That being said, you can momentarily disableextensions
and then turn it back on when needed. The below example shows how disabling it will allow you to use it in the REM
comment and then enabled again after to show allow extensions:
@echo off
setlocal disableextensions
REM %~ will strip surrounding quotes if any"
endlocal
echo my batch file is %~0
I think it is clearly covered in quite a few docs that cmd will interpret the arguments before comments, see the example in @LotPings comment as well as @aschiphl's post. That being said, you can momentarily disableextensions
and then turn it back on when needed. The below example shows how disabling it will allow you to use it in the REM
comment and then enabled again after to show allow extensions:
@echo off
setlocal disableextensions
REM %~ will strip surrounding quotes if any"
endlocal
echo my batch file is %~0
edited Nov 21 '18 at 9:18
answered Nov 21 '18 at 6:12
Gerhard BarnardGerhard Barnard
8,65631232
8,65631232
3
Instead ofsetlocal enableextensions
I would useendlocal
to return to the former state (default) and to the former environment, thus having the same state as in the original code...
– aschipfl
Nov 21 '18 at 9:01
@aschipfl true yes, I think I just wanted to demonstrate enable and disable, but will change.
– Gerhard Barnard
Nov 21 '18 at 9:18
Thanks for the workaround idea! Considering the extra lines to work around this, I simply used a valid expression there: %~1.
– codesniffer
Nov 22 '18 at 1:27
add a comment |
3
Instead ofsetlocal enableextensions
I would useendlocal
to return to the former state (default) and to the former environment, thus having the same state as in the original code...
– aschipfl
Nov 21 '18 at 9:01
@aschipfl true yes, I think I just wanted to demonstrate enable and disable, but will change.
– Gerhard Barnard
Nov 21 '18 at 9:18
Thanks for the workaround idea! Considering the extra lines to work around this, I simply used a valid expression there: %~1.
– codesniffer
Nov 22 '18 at 1:27
3
3
Instead of
setlocal enableextensions
I would use endlocal
to return to the former state (default) and to the former environment, thus having the same state as in the original code...– aschipfl
Nov 21 '18 at 9:01
Instead of
setlocal enableextensions
I would use endlocal
to return to the former state (default) and to the former environment, thus having the same state as in the original code...– aschipfl
Nov 21 '18 at 9:01
@aschipfl true yes, I think I just wanted to demonstrate enable and disable, but will change.
– Gerhard Barnard
Nov 21 '18 at 9:18
@aschipfl true yes, I think I just wanted to demonstrate enable and disable, but will change.
– Gerhard Barnard
Nov 21 '18 at 9:18
Thanks for the workaround idea! Considering the extra lines to work around this, I simply used a valid expression there: %~1.
– codesniffer
Nov 22 '18 at 1:27
Thanks for the workaround idea! Considering the extra lines to work around this, I simply used a valid expression there: %~1.
– codesniffer
Nov 22 '18 at 1:27
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53403485%2fbatch-script-interpreting-content-inside-comment%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
I think that happens in an early parsing phase, for details see how-does-the-windows-command-interpreter-cmd-exe-parse-scripts
– LotPings
Nov 21 '18 at 0:59
Wow! Just when I thought Batch couldn't be more brain dead, I learn about this, and find a new low. Sigh...
– codesniffer
Nov 22 '18 at 1:25