ralph
8/7/2011 4:53:00 PM
On Sun, 7 Aug 2011 08:32:32 -0400, "Mayayana"
<mayayana@invalid.nospam> wrote:
>| Since the space character acts as the separator between commands in the
>| command line it doesn't make much sense to enclose the whole command line
>| in quote characters. Only enclosing one or more parts ('commands') of the
>| command line in quote characters makes sense since the quote characters
>| mean that any enclosed space character shall _not_ be treated as as the
>| command separator but simply as a space character.
>|
>
> Yes, but in this case the whole command line is just a
>file path. As Garry said, a path is typically wrapped if there
>are spaces, but it doesn't seem to make sense for VB to
>send a path through with quotes around it.
>
I doubt "VB" has much to do with it. The VB CommandLine$ pretty much
just passes on what it is given. [*note below]
> I've run into this problem so seldom that I wondered
>if there were other facotrs involved, other than whether
>a path has spaces. Perhaps memory is tricking me, but I
>don't remember this being an issue on Win9x.
>
As Nobody noted: There is not enough information to provide an answer
as it depends on the 'tool' that generated the command line, and, if
any, any intermediate 'tool' that retrieves that command line for the
client.
Spaces as a delimiter is only of interest to a parser. As a practical
factor we only surround some arguments with double quotes so as to not
confuse a parser.
Note there can be two parsers involved that we don't want to confuse
in the process of presenting a command line to a Windows program. The
first one is the Command Line parser itself (as determined by
COMSPEC). We would have problems if we attempted to pass "&&" or "<<"
as arguments, for example. The second one is the C runtime library
which takes the parsed command line and packs it into a character
array (the argv block).
*I not exactly sure how VB6 'constructs' its command line. Back in the
day it appeared VB took the C library main argument argv memory block
and simply replaced the nuls with spaces. It always seemed strange to
me that they didn't simply provide a String array - after all they had
all the information. Thus it is more likely the VB developers took the
quick way out and used the MS specific preprocessor directive "__ARGV"
to grab the command line, and the 'code' I saw 'stripping away' nuls
came from that directive. In any case it doesn't matter, since when
the smoke clears VB gets a straight single string. <g>
When you start investigating "command lines" it is useful to
appreciate that there are two separate things going on here (just as
there is with any computing paradigm) -
The first one is the protocol, or how it ought to work;
the second is the implementation, or how it does work.
M$ uses a modified "DEC" protocol and part of that protocol says
'strings' will be surrounded by double quotes.
It also had the specification that single quotes would delimit
"literal values", but you'd have to go back 20+ years to see any
mention of it, and AFAIK nothing in the Windows world ever implemented
it outside of a few data-centric tools.
So theoretically a typical command line should look like this ...
ProgramA "filepath"
But the default, or actually better put since everything ends up as a
'string' anyway, the following is perfectly acceptable to most
clients.
ProgramA filepath
Some parsers (the implementers) would strip the double quotes, others
would not. This used to be a bit of a PITA in the old days, especially
when working with mixed platforms - UNIX, Windows, and different
compilers. You had to go the extra step of always checking for double
quotes and trimming them. So yes, I've seen this in the past. But now
days it is quite rare since we tend to work with a single platform and
compiler. For shrink wrap applications I still usually check 'n strip
- out of pure habit and old age. I hate telephone calls. <bg>
Also for completeness the protocol provides for the "/" to serve as an
option flag, but there is no implementation enforcement of such
critters in Windows.
All clients are pretty much on their own when it comes to command line
'reading'. The UNIX world is lucky as AT&T provided the getopts
utility. It served as a de facto standard command line protocol
implementer and enforcer. Windows never got one. More's the pity - a
ton of aggravation could have been avoided. <g>
Track down the specific actors involved in the transaction of interest
and you'll have your solution. Particularly note if COMSPEC is
involved, ie, whether you are using the DOS parser or not.
hth
-ralph