On 10/18/2015 10:15 PM, Eli Zaretskii wrote: >> Date: Mon, 19 Oct 2015 13:32:51 +0900 >> From: "Stephen J. Turnbull" >> Cc: Random832 , >> emacs-devel@gnu.org >> >> Eli Zaretskii writes: >> > Random832 writes: >> >> > > Yes, sorry. A typical Windows program (at least, one compiled with >> > > MSVC's setargv.obj) will try to interpret wildcards in any part of >> > > CommandLineToArgv's result which contains a ? or * character, with >> > > no provision to prevent it from doing so. (In particular, double >> > > quotes have no effect). >> > >> > This actually depends on the startup code. The latest release of >> > mingw.org's MinGW runtime does allow you to quote wildcard characters. >> > And on Windows XP and older even the other runtimes allow that. >> > >> > In any case, this is not an Emacs problem. >> >> Of course it is, in a security context. I don't think it matters >> anywhere near as much as code injection, but if Emacs is built with >> one of those runtimes that doesn't allow wildcards to be disabled, its >> users will be affected. >> >> I think it probably can be immediately judged irrelevant (and perhaps >> that's what you meant) if Emacs is normally built with a runtime that >> doesn't interpret quoted wildcards, and the runtimes that always >> interpret wildcards are not supported. > > That's a misunderstanding: the runtime in question is the one used > with the program that Emacs invokes, not the one used to run Emacs > itself. On MS-Windows, the expansion of wildcards on the command line > is done by the application which accepts the command line (in its > startup code, before the main function is invoked), so that's what > determines whether a quoted "*" will or will not be expanded. The > invoking Emacs cannot control or affect that in any way. But maybe we can make the argument-quoting style a particular program expects a user-customizable variable.