Re: [Mingw-users] running programs from MSYS with quotes

[Keith M. <kei...@us...>]

On 25/06/14 14:51, Eli Zaretskii wrote:
>> Date: Wed, 25 Jun 2014 01:05:55 +0100
>> From: Keith Marshall
>>
>> On 24/06/14 23:11, Yuri Kanivetsky wrote:
>>> If I understand you correctly, using single quotes is no better than using
>>> double quotes here. Both commands:
>>>
>>> $ cmd //c '"cmd" /c echo test'
>>> $ cmd //c "\"cmd\" /c echo test"
>>>
>>> produce the same command line:
>>>
>>> c:\Windows\system32\cmd.exe /c "\"cmd\" /c echo test"
>>
>> Correct.  The inner pair of double quotes are literal; according to both
>> http://msdn.microsoft.com/en-us/library/a1y7w461.aspx and
>> http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
> 
> Those URLs describe what the standard C/C++ library startup code does
> to convert the command line into the argv[] array.

Sure.  A perfectly reasonable expectation, for a system intended to
support applications using precisely that framework.

> But a program doesn't have to use that startup code, it can provide its own (and in
> fact, MinGW 4.x actually does).

Well, yes, this is true in its default configuration, which attempts to
provide saner handling of wildcard globbing tokens -- in response to
your own bug report, Eli, and faced with deliberatly broken globbing
behaviour introduced by Microsoft, with the advent of Vista.  However,
aside from the improved globbing behaviour, this replacement startup
code is careful to preserve the parsing effect of the original Microsoft
_getmainargs() handler; this may be readily proven by compiling my
earlier test program with the '-D CRT_GLOB_OPTIONS=0' flag, (which has
the effect of disabling MinGW's alternative parser, and simply calling
_getmainargs() in its stead); when compiled thus, the output from my
examples remains *identically* the same.

> It can even (gasp!) not be a C/C++ program.

Sure.  However ...

> IOW, these are in no way Windows-wide requirements, they are limited
> to programs that use standard C/C++ libraries for their startup code.

... to reiterate, I don;t consider this to be an unreasonable
expectation, for a system designed to interoperate with MSVCRT.DLL,
(which provides precisely this startup API).

> In particular, those URLs are not applicable to how cmd.exe treats
> quoted command arguments.
> 
>>> And they doesn't do what they are supposed to do. The point here is to pass
>>> the following command line to the process:
>>>
>>> c:\Windows\system32\cmd.exe /c ""cmd" /c echo test"
>>
>> Well, applying the parsing logic from each of those MSDN references,
>> that is identically equivalent to
>>
>>   c:\Windows\system32\cmd.exe /c cmd" /c echo test"
>>
>> because the first pair of quotes delimit an empty string.
> 
> That's not how cmd.exe handles that command line.

[... snip ...]

> IOW, the OP is correct: MSYS ought to have special support for
> invoking cmd.exe by either automatically enclosing cmd.exe commands in
> quotes, or at least allowing users some fire escape whereby they could
> achieve that effect.

I don't disagree; that's why I suggested that the MSYS maintainer might
consider providing a simple (generic) wrapper, which could hand off
explicitly consistent command lines in accordance with cmd.exe's arcane
quoting expectations -- and yes, even if you don't consider cmd.exe to
be arcane, the quoting syntax under discussion certainly *is*, IMO.

>>> AFAIR, some programs, amongst which are cmd, start, hstart, treat their
>>> command line specially. When given things like `""cmd" /c echo test"`, they
>>> just ignore the outer quotes or treat the whole thing as one big quoted
>>> argument.
>>
>> Then such programs violate Microsoft's own parsing conventions
> 
> No, they don't; see above.  But even if they did, cmd.exe is not some
> obscure or "arcane" program.

You are, of course, fully entitled to that opinion; personally, I have
always considered cmd.exe, (and command.com before it), to be arcanely
dysfunctional and inadequate -- an opinion to which I am equally
entitled, so please respect it.

> You cannot have a useful Windows program that invokes other programs,
> if it doesn't know how to invoke cmd.exe correctly and reliably.

Why?  We are taking about a *shell* here -- a program which *replaces*
cmd.exe, with (IMO) a much saner alternative.  I've used it as such,
*exclusively*, for years, and I have never felt in the slightest way
disadvantaged that it may not "know how to invoke cmd.exe correctly and
reliably"; I have never found cmd.exe to be even remotely useful.

>> MSYS has been developed to interoperate with applications which do
>> conform to those conventions, and accordingly DTRT.
> 
> This means, plain and simple, that MSYS is inappropriate for invoking
> cmd.exe.  Which is not a catastrophe, at least not for people who,
> like me, limit MSYS usage to configuring and building Posix software,
> where cmd.exe does not need to be invoked.  But other MinGW users, who
> do like using MSYS in routine operation of their Windows boxes, might
> not be pleased by this conclusion.

See above.  I've used MSYS precisely for "routine operation of my
Windows box" for years, without ever experiencing the slightest hitch.
(Yes, I know there may be some esoteric corner cases, which it doesn't
handle well, and perhaps I've been lucky that they haven't affected me;
there have also been some bugs which have been fixed along the way).

> It would be nice if MSYS developers added proper support for passing
> quoted commands to cmd.exe.

It could be handled via a wrapper, as I've suggested; however, unless
someone can propose a deterministic implementation, I definitely will
not advocate any deeper, probably heuristic, and therefore broken by
design, mechanism for achieving this.

-- 
Regards,
Keith.