Interesting variable substitution error on commented line.
Jim Robinson
'call' and 'for', I had some code very similar to the following:
01 :Function_Name
02 set var1=%1
03 ::set var2=%~var1%
04 echo var1
05 goto :eof
Which kept giving me an error:
==================================
D:\>vartest.cmd
D:\>set var1=whatever
The following usage of the path operator in batch-parameter
substitution is invalid: %~var1%
For valid formats type CALL /? or FOR /?
D:\>::set var2=%~var1%
==================================
This is the only time I have seen evidence that a ::'d line is parsed
at all, unlike REM'd lines. Are there other situations that any of you
know of? Granted, this error was pretty easy to spot, but I HAD come
to expect CMD completly ignoring :: lines. This means I'll need to be
more careful!
--
Jim Robinson
set email=jim....@ix.netcom.com
echo %email:.n.=n%
Uno
"Jim Robinson" <jim....@ix.netcom.com> wrote in message news:rbGIb.14324$lo3....@newsread2.news.pas.earthlink.net...
> While playing around with a script, but before reading the help on
> 'call' and 'for', I had some code very similar to the following:
>
> 01 :Function_Name
> 02 set var1=%1
> 03 ::set var2=%~var1%
> 04 echo var1
> 05 goto :eof
>
> Which kept giving me an error:
> ==================================
> D:\>vartest.cmd
>
> D:\>set var1=whatever
> The following usage of the path operator in batch-parameter
> substitution is invalid: %~var1%
>
>
> For valid formats type CALL /? or FOR /?
>
> D:\>::set var2=%~var1%
> ==================================
Very strange.
The same thing happens with REM,
it is sufficient the following line to
get an error message:
::%~
Mark V
First I've heard of it. Looks like a new bug discovery.
Same here W2K, SP4
I too have use ":: " fully expecting following text to be completely
ignored...until now. :-)
Uno
> First I've heard of it. Looks like a new bug discovery.
http://groups.google.it/groups?selm=mzCeKqBCEF5%2BEwff%40ponle.demon.co.uk&oe=UTF-8&output=gplain
Mark V
> Time to scan your PC with an external virus scanner,
> e.g. on www.antivirus.com ("free online scan").
This has nothing to do with a virus. Did you even try it?
Either a "bug" or a change in behavior (intentional or not) in CMD
processing of ":: " lines.
Mark V
I'll be darned. Learn something new....
Thanks for the reference.
So this appears to be the behavior in XP as well. Anyone with 2K3?
Mark V
> Oh. And we thought you had a virus or Trojan... Guess it was
> that crappy MS coding at fault. :-)
>
ROTFL! Thanks Si
Timo Salmi
> In alt.msdos.batch.nt Jim Robinson wrote:
> > While playing around with a script, but before reading the help on
> > D:\>::set var2=%~var1%
> I too have use ":: " fully expecting following text to be completely
> ignored...until now. :-)
Let's speculate a bit. One potential cause of that bug could be if
the command lines are parsed backwards (I seem to recall from
somethere that they they would be). Then the faulty %~var1%
reference would cause the error before the :: is reached, if the
parser is badly designed. But this is guesswork. I really don't
know.
I also notice that the error message persists even if one tries to
redirect it. At least as in
:: set var2=%~var1% > nul 2>&1
(with or without the ::) so obviously the redirection method does
not work for syntax errors, only for errors reported by a
syntactically correct line.
Walter (Briscoe), I note from the reference given in another message
that you run on this problem in June 2003:
http://www.google.com/groups?selm=mzCeKqBCEF5%2BE...@ponle.demon.co.uk
Have you since then got any explanation for your interesting discovery?
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful script files and tricks ftp://garbo.uwasa.fi/pc/link/tscmd.zip
Timo Salmi
> While playing around with a script, but before reading the help on
> The following usage of the path operator in batch-parameter
> substitution is invalid: %~var1%
> This is the only time I have seen evidence that a ::'d line is parsed
> at all, unlike REM'd lines. Are there other situations that any of you
Unfortunately, the same error occurs if REMmed instead of ::
commented. Fortunately, even if definitely ugly, this works around
it:
@echo off & setlocal enableextensions
goto _afterComment
rem set var2=%~var1%
:_afterComment
echo We made it!
endlocal & goto :EOF
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's FAQ materials at http://www.uwasa.fi/~ts/http/tsfaq.html
Al Dunbar
"Timo Salmi" <t...@UWasa.Fi> wrote in message
news:bt0tpm$6...@poiju.uwasa.fi...
> Jim Robinson <jim....@ix.netcom.com> wrote:
> > While playing around with a script, but before reading the help on
> > 03 ::set var2=%~var1%
>
> > The following usage of the path operator in batch-parameter
> > substitution is invalid: %~var1%
>
> > This is the only time I have seen evidence that a ::'d line is parsed
> > at all, unlike REM'd lines. Are there other situations that any of you
>
> Unfortunately, the same error occurs if REMmed instead of ::
> commented. Fortunately, even if definitely ugly, this works around
> it:
>
> @echo off & setlocal enableextensions
> goto _afterComment
> rem set var2=%~var1%
> :_afterComment
> echo We made it!
> endlocal & goto :EOF
As far as unexpected behaviour of lines starting with ":: " is concerned, I
believe that the documentation mentions only one use for a line starting
with a colon, and that is to define a label. The fact that many of us have
come to like using ":: " as a comment prefix that stands out as "not a
command" more than "REM" is only a side effect (imho) of coding shortcuts.
The fact that it is not a bullet-proof way to create a comment line
containing *anything at all* is certainly unfortunate, but I would not think
it necessarily a bug.
/Al
Timo Salmi
> > > 03 ::set var2=%~var1%
> > > substitution is invalid: %~var1%
> > Unfortunately, the same error occurs if REMmed instead of ::
> with a colon, and that is to define a label. The fact that many of us have
> come to like using ":: " as a comment prefix that stands out as "not a
> command" more than "REM" is only a side effect (imho) of coding shortcuts.
> The fact that it is not a bullet-proof way to create a comment line
> containing *anything at all* is certainly unfortunate, but I would not think
> it necessarily a bug.
Fair enough, Al. But the similar behavior of REM can be considered a
bug. Right? And that is what happens.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Al Dunbar
"Timo Salmi" <t...@UWasa.Fi> wrote in message
> Al Dunbar <alan-no-...@hotmail.com> wrote:
> > "Timo Salmi" <t...@UWasa.Fi> wrote in message
> > > Jim Robinson <jim....@ix.netcom.com> wrote:
> > > > 03 ::set var2=%~var1%
> > > > substitution is invalid: %~var1%
>
> > > Unfortunately, the same error occurs if REMmed instead of ::
>
> > with a colon, and that is to define a label. The fact that many of us
have
> > come to like using ":: " as a comment prefix that stands out as "not a
> > command" more than "REM" is only a side effect (imho) of coding
shortcuts.
> > The fact that it is not a bullet-proof way to create a comment line
> > containing *anything at all* is certainly unfortunate, but I would not
think
> > it necessarily a bug.
>
> Fair enough, Al. But the similar behavior of REM can be considered a
> bug. Right? And that is what happens.
Whether or not we consider such apparent anomalies "bugs", "unexpected
behaviours", "unfortunate behaviours", or something else is secondary to
what use we make of such facts of batch life.
Yes, I agree that, given the definition of the "REM" command, one could
reasonably expect it to accept ANY sequence of characters, regardless of
whether that would constitute a syntax error in another context. But we all
know the nature of variable substitution and how it happens before the
command is fully parsed, and that this causes apparently buggy behaviour, at
least when considered by newbies. And we are all cognizant of the fact that
some character sequences are inherently problematic when we try to consider
them as all textually equivalent. I think there are even some known issues
regarding the REM command itself in this case, but here my memory fails.
But we all realize that, even the lowly, do-nothing REM command is parsed,
at least far enough to know it is a REMark, and that the first non-blank
token is not "/?", otherwise this command:
REM /?
would behave as a REMark rather than as a request for help about the REM
command.
And we all know that the syntax of at least some of the "command /?"
commands is different from that of the commands about which we are trying to
get help, and yet again different from each other. What would you expect
these commands to do (results on XP given below as well):
REM /? test - "test was unexpected at this time"
REM test /? - this is ignored as a remark
NET /? user - displays same help info as the next command
NET user /? - displays same help info as the previous command
Whether all such anomalies of the batch programming language we have come to
know and love^H^H^H^H use constitute a "bug" probably depends on the intent
of the programmer more so than on the expectations of the users. Was that
intent to create a bullet-proof programming language? REM /? says this:
"Records comments (remarks) in a batch file or config.sys". Can anyone say
that it does NOT do that?
I think this is a natural consequence of the way it has developed from the
very simple workhorse tool of a very simple o/s to a still very simple tool
of an incredibly complex o/s environment, combined with the fact that it is
not sold to a clientele who demands that "issues" be fixed.
They took obvious coding shortcuts in the early days, and these have, in
fact, developed into the quirky side-effects that our more sophisticated
batches have come to rely on. I think for us to call some of these bugs and
others features is something like the pot calling the kettle black. There is
also some evidence of ego in this, as we are much more likely to be
accepting of that "feature" we have been using for decades even though it is
a side-effect, than of the newly discovered "bug", which makes us seem a bit
less knowledgeable than we would like to think. ;-)
Getting back to my first paragraph, the solution, imho, is to avoid pushing
the language. Why would you need a syntactically incorrect construct in a
REM (or ":: ") statement, any way? Rather than figure out how to handle
special characters in a comment, I would prefer to keep the comments in
plain text and use my own CPU cycles to solve problems in the executable
code of my scripts.
Alternately, one could as easily say that the entire set of batch processing
programs (command.com and cmd.exe) contain mostly bugs.
Finally, here is another interesting anomaly associated with the REM
command. What do you suppose happens when you run the following batch file?
@echo off
echo/starting
REM replace this with a command to actually do something
echo/done
(rem)
now is the time for
all good men to
jump over the lazy
brown fox.
A bug? A feature? Or a time-wasting oddity?
/Al
Al Dunbar
"Al Dunbar" <alan-no-...@hotmail.com> wrote in message
news:Ox1Jb.906684$9l5.799065@pd7tw2no...
>
> "Timo Salmi" <t...@UWasa.Fi> wrote in message
> news:bt1t69$e...@poiju.uwasa.fi...
> > Al Dunbar <alan-no-...@hotmail.com> wrote:
> > > "Timo Salmi" <t...@UWasa.Fi> wrote in message
> > > > Jim Robinson <jim....@ix.netcom.com> wrote:
> > > > > 03 ::set var2=%~var1%
> > > > > substitution is invalid: %~var1%
<snip>
> A bug? A feature? Or a time-wasting oddity?
The above should have read:
> A bug? A feature? Or a time-wasting oddity (much like most of my posts
;-)?
/Al
Jim Robinson
<snip>
> This is the only time I have seen evidence that a ::'d line is
> parsed at all, unlike REM'd lines. Are there other situations
> that any of you know of? Granted, this error was pretty easy to
> spot, but I HAD come to expect CMD completly ignoring :: lines.
> This means I'll need to be more careful!
I have to agree with Al Dunbar, the behavior of unsupported
'features' like :: should not be considered a bug. In fact, I only
noticed it when using :: while debugging my own sloppily written
script.
So I of course need to agree with Timo Salmi as well, as it is
bothersome at best when the documented comment string exihibits the
same behavior.
Now, let me make it clear that 'having' and 'needing' to agree with
the likes of Al and Timo in no way implies that I dislike doing so.
I have a loooooong way to go before becoming even remotely as
competent as either. Al's (rem) example is a perfect example. How
the H$!! did you run across that, Al?
Timo Salmi
> > bug. Right? And that is what happens.
> Whether or not we consider such apparent anomalies "bugs", "unexpected
> behaviours", "unfortunate behaviours", or something else is secondary to
Perhaps best "anomalies", as you said later on in your original
message.
> what use we make of such facts of batch life.
Yes. We know that in particular in the much more limited MS-DOS
batch programming some of the oddities are in fact utilized to solve
some task. Despite being in the process writing the NT scripting FAQ
I am not yet as familiar with all the NT scripting tricks to know if
corresponding cases exist. The case we discuss now is something to
be avoided. We do not (yet?) know how to maybe even utilize it.
> Yes, I agree that, given the definition of the "REM" command, one could
> reasonably expect it to accept ANY sequence of characters, regardless of
> whether that would constitute a syntax error in another context. But we all
> know the nature of variable substitution and how it happens before the
> command is fully parsed, and that this causes apparently buggy behaviour, at
> least when considered by newbies. And we are all cognizant of the fact that
However, the less complicated (that's probably why)
MS-DOS+Win../95/98/ME REM or :: does not dispaly the same anomaly.
> Getting back to my first paragraph, the solution, imho, is to avoid pushing
> the language. Why would you need a syntactically incorrect construct in a
> REM (or ":: ") statement, any way? Rather than figure out how to handle
Exactly. Yet, it is good and reasonable that we become aware of such
anomalies. I've made a brief item about it in my FAQ. I'll include
your view's message-id as a good reference.
Al Dunbar
"Jim Robinson" <jim....@ix.netcom.com> wrote in message
news:SQ7Jb.15788$lo3....@newsread2.news.pas.earthlink.net...
> Jim Robinson <jim....@ix.netcom.com> wrote in
> news:rbGIb.14324$lo3....@newsread2.news.pas.earthlink.net:
> <snip>
> > This is the only time I have seen evidence that a ::'d line is
> > parsed at all, unlike REM'd lines. Are there other situations
> > that any of you know of? Granted, this error was pretty easy to
> > spot, but I HAD come to expect CMD completly ignoring :: lines.
> > This means I'll need to be more careful!
> </snip>
>
> I have to agree with Al Dunbar, the behavior of unsupported
> 'features' like :: should not be considered a bug. In fact, I only
> noticed it when using :: while debugging my own sloppily written
> script.
I would like to point out, however, that my suggestion these things be
referred to as other than bugs is more for our own benefit than to avoid
criticizing the team that developed CMD.EXE.
> So I of course need to agree with Timo Salmi as well, as it is
> bothersome at best when the documented comment string exihibits the
> same behavior.
Agreed there as well.
> Now, let me make it clear that 'having' and 'needing' to agree with
> the likes of Al and Timo in no way implies that I dislike doing so.
> I have a loooooong way to go before becoming even remotely as
> competent as either. Al's (rem) example is a perfect example. How
> the H$!! did you run across that, Al?
No idea. For some unknown reason I typed it at a command prompt, only to be
further prompted with the familiar "More? ". So then I tried it in a batch
file. It *COULD* be used to include a block of comments at the end of a
batch file, however, it will still behave badly if you include any special
characters or invalid environment variable expansion constructs ;-)
Just one more quirk with questionable value.
/Al
Al Dunbar
"Timo Salmi" <t...@UWasa.Fi> wrote in message
> Al Dunbar <alan-no-...@hotmail.com> wrote:
> > "Timo Salmi" <t...@UWasa.Fi> wrote in message
> > > Fair enough, Al. But the similar behavior of REM can be considered a
> > > bug. Right? And that is what happens.
>
> > Whether or not we consider such apparent anomalies "bugs", "unexpected
> > behaviours", "unfortunate behaviours", or something else is secondary to
>
> Perhaps best "anomalies", as you said later on in your original
> message.
>
> > what use we make of such facts of batch life.
>
> Yes. We know that in particular in the much more limited MS-DOS
> batch programming some of the oddities are in fact utilized to solve
> some task. Despite being in the process writing the NT scripting FAQ
> I am not yet as familiar with all the NT scripting tricks to know if
> corresponding cases exist. The case we discuss now is something to
> be avoided. We do not (yet?) know how to maybe even utilize it.
I agree with your comments relative to the pre- and post- NT era. NT and
later versions of CMD.EXE have added in features that do things we used to
have to handly by relying on side effects of some of the peculiar little
oddities of the older command.com.
Personally, I try to avoid "tricks" altogether when I code in batch, or at
least document them as such. Better to stick to the documented features of
the language than to rely too heavily on things more likely to change in
later versions. Hey, it's only a "batch" language designed to help us
"automate" the use of the available commands. If you want/need something
with more power, or to be able to easily treat all text characters as
equivalent, there are more robust platforms.
That said, I use "::" exclusively for comments because they stand out better
that way.
> > Yes, I agree that, given the definition of the "REM" command, one could
> > reasonably expect it to accept ANY sequence of characters, regardless of
> > whether that would constitute a syntax error in another context. But we
all
> > know the nature of variable substitution and how it happens before the
> > command is fully parsed, and that this causes apparently buggy
behaviour, at
> > least when considered by newbies. And we are all cognizant of the fact
that
>
> However, the less complicated (that's probably why)
> MS-DOS+Win../95/98/ME REM or :: does not dispaly the same anomaly.
Now that's interesting. Probably because cmd.exe contains so much new code,
that some of the old parts might have been re-written. But since there is no
documented explanation that ":: " can be used as a comment prefix (at least
none that I am aware of), one could argue that a line starting with ":: "
should be considered a line in error. As such, the most correct response
would likely be:
'::' is not recognized as an internal or external command, operable
program or batch file.
Consider a simple command-line calculator program that might have been
developed a long time ago to "add positive integers". Version two comes out
allowing them to be multiplied as well. Then someone points out that he had
been using the original version to successfully add negative integers, but
has found that the new version generates an error message instead: "Calc
program can handle only positive integers". We might like the behaviour of
version one because we have a need to calculate with negative integers that
had not been foreseen by the developer, but it is version two that,
technically, comes closer to meeting the dsign specifications.
The problem with the batch language is that the design specifications,
especially those relating to invalid input, seem not to be written in stone
anywhere, but mainly in our expectations, which are based mostly on common
sense and the principle of "least astonishment".
> > Getting back to my first paragraph, the solution, imho, is to avoid
pushing
> > the language. Why would you need a syntactically incorrect construct in
a
> > REM (or ":: ") statement, any way? Rather than figure out how to handle
>
> Exactly. Yet, it is good and reasonable that we become aware of such
> anomalies. I've made a brief item about it in my FAQ. I'll include
> your view's message-id as a good reference.
I am flattered, thanks.
/Al