|
From: Eli Z. <el...@gn...> - 2014-06-27 20:30:06
|
> Date: Fri, 27 Jun 2014 20:35:10 +0100 > From: Keith Marshall <kei...@us...> > > >> 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. The system supports more than that single framework. In fact, Windows's native behavior is limited to command line as a single string; that's why the most primitive API, CreateProcess, accepts command arguments in that form, and in that form only. Breaking it into argv[] is a bow towards C standards, which explicitly require that. > > 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). MSVCRT.DLL is an implementation of the standard C library. Non-C programs don't need to be compatible with it. > >> 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. We can agree to consider cmd.exe to be dysfunctional, but we cannot ignore it on that ground. > > 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? Because a Windows program that cannot invoke the standard Windows command shell correctly will be very limited in its usefulness. It cannot run batch files, for example, nor built-in cmd commands. > 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. Sure, if you avoid cmd.exe, you trivially don't need to be able to invoke it. But then you are avoiding Windows in general, and that's not what we are talking about here. > > 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. I said "inappropriate for invoking cmd.exe". You did what you did without invoking cmd.exe, so how does that invalidate my claim? > > 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. I already proposed a deterministic implementation. I will repeat it here: just wrap the entire cmd.exe command line in a pair of quotes, and otherwise leave the command line intact. This works; I implemented this in at least 2 widely used programs (with a 3rd to follow soon), and I have yet to see a single complaint. Note that this method of quoting will work only with cmd.exe; for other programs doing what MSYS does already is almost always TRT. So you need to have two methods: one for cmd.exe (and I'm told also 'start' and 'hstart'), the other for everything else. |