Interesting comments, see my responses in-line...
Alexander Suhovey said:
Haha, that was a good one! Love it!
I can't seem to buy a good straight line these days, so when one comes along
for free, I go for it!
Same applies to parentheses and quotes, isnt it?
Yes and no. Yes, the prevention of a trailing blank isn't the primary reason
for them, but no: the parentheses and quotes at least surround the command
they are there to protect, whereas the ampersand simply follows it, a fact
that I contend makes its meaning at least somewhat less obvious. Also, the
quotes are normally understood to differentiate what is in a string from
what is not in a string, and the parenthesis' function is to group one or
more commands, thereby similarly differentiating what is in the command(s)
from what is not. If what is not happens to be a space, well that is still
simply these things doing their normal function, when this poor
(non-existent) space is given short shrift.
We could argue endlessly, or we could do a test with a hundred batch
programmers and ask them to modify this script to make it more readable, but
still yielding the same result:
set DAY=%%1&(set TIME=%%2)
I bet that the "&" would either be replaced with an endline character or
preceded and followed with a blank MORE often than would the final ")" be
preceded by a blank.
In my mind, then, it is not really which method is most aligned with the
original intent of the feature as I initially suggested, but which will
result in a more intuitive understanding of what it is doing in this
context.
The problem here is not
somebody putting extra trailing spaces by accident, it's some text editors
that can automatically do that for whatever reason they have.
That may indeed be the cause of the majority of cases, however, I see the
problem as there *being* a trailing space whose presence creates a problem.
And that problem is further exascerbated by the difficulty of knowing the
blank is there when it is followed by more whitespace in the form of an
endline character.
If someone exclusively used an editor that displayed blanks as grey dots,
then it might be less important for them to do this (unless, of course, this
is one of the editors that indiscriminately pads lines with blanks), but one
can never be sure that one's script will never be edited by someone else
with a different editor.
Also, you
probably know that some forum engines have this problem too: when you post a
code snipplet using
tags, every line inside gets an extra
trailing space which can very well result in broken batch code if you
copy-paste it to your text editor.
Which is one reason for the many posts over the years recommending the
explicit use of parentheses, or, sometimes, double-quotes.
Sure, but I don't see how it's that bad other than it looks ugly. There are
other things in batch scripting that weren't meant to be used in the way
they are used by scripters today.
I agree, like 80%! Ugliness alone may not be a bad thing; ugliness that
interferes with one's ability to detect subtle nuances about what is really
going on in a script, now *that* is a bad thing.
Like "set /p" command which purpose is to provide interactive user input
facility but somebody figured it also can be used to append the output text
to the same line.
Or ping as a way to add pauses to the script.
@echo off
set /p foo="Working ..."<nul
for /l %%i in (1,1,40) do (
ping -n 1 127.0.0.1>nul 2>&1
set /p foo="."<nul
)
echo Done.
Sure, I use those techniques, and more... That is because the side effects
in question are sometimes almost important as the obvious intent of such a
feature, and the side effect is not really available otherwise without
writing an executable to do it. But, ideally, one should never use code for
its side effects unless the meaning is documented, or at least in general
use in the batch scripting community.
/Al
