billious said:
Al Dunbar said:
billious said:
dbareis wrote:
[snip - START command documented syntax]
Dennis is right, though, in deducing from the help text that the
title is "optional". It is just that it is only optional when it is
not required.
/Al- Hide quoted text -
- Show quoted text -
Well, it *is* optional in that it is not always required. Where the docs
fail is in not explaining the why's and the wherefore's of this, leaving
it up to this newsgroup to explain.
Also, I suspect that the help file info was written after the command was
developed, and by people other than the development team. We can argue
that the help text is inaccurate, or we could lay more of the blame on
the command itself. Unfortunately, neither case will cause either of the
blameworthy parts to be fixed.
/Al
...
set exe="C:\a b\c.exe"
start %exe% 1.txt
Oh dear, you don't really believe I didn't automate the testing?
Here's one of the batches I used:
I did it this way to be sure of trying all combinations.
I would have expected the programmer to have consistently interpreted
parameters as tokens separated by er, separators - each string being a
token, and where a token is required to contain a separator, then the
string needs to be quoted. It seems from the way that START is implemented
that this philosophy was NOT followed.
Granted.
Why change horses in midstream?
Indeed. So, we are on this horse now...
The failure to implement 0D/0o or date/u is clearly a developer's
decision. It would seem that these decisions were made without adequate
consideration of the consequences.
IMHO, when batch commands were first developed, I strongly suspect that they
had very little idea of the extent to which users would run into problems
because of our innate tendency to assume that they were developing a
consistent and sophisticated programming language rather than slightly
extending an interactive command processor. ;-)
I can't see that it's relevant whether the documentation was an
afterthought performed by a different section or whether it was done by
the developers.
That was just my observation, not an actual argument. In fact, if we cannot
tell which might be the case then it doesn't really matter how we wound up
with what we have to deal with.
Whoever did it didn't use the verification tools available, or disregarded
the results.
I suspect that, whatever verification processes may have been used simply
demonstrated that the code worked the way they expected it to. It does seem,
however, that they were not sticklers for consistency and simplicity in how
the command processes its arguments.
I've been astonished by encountering so programmers who seem to have
difficulty in this area. After all, their profession requires strict
adherence to syntax and spelling - they even seem to revel in
StupidLongMixedCaseVariableNames.
We all have our style preferences, however, I don't see where it is clear
that the developers of the START command are of the SLMCVN ilk.
What now appears to be the case is that quoted parameters to START are
processed in an irregular manner, which wouldn't have been evident had the
discussion been restricted the the original particular example..
So then, it's a good thing that we followed off on this tangent?
/Al
