On 4/25/11 1:58 AM, Jason Rumney wrote:
> On 25/04/2011 16:49, Daniel Colascione wrote:
> 
>> 1. we can have cmdproxy level-two-dequote the supplied command line
>> before giving it to CreateProcess, or
>>
>> 2. we can remove optimization described above and have cmdproxy always
>> run the command interpreter.
>>
>> I favor the second option: cmd starts very quickly, and we don't save
>> much time by bypassing it.
> 
> IIRC, this "optimisation" isn't about saving time, but about avoiding
> limitations in cmd.exe where possible.
> 
> Another possibility is to make the decision whether to use cmd.exe or
> not based on the presence of "level 2" metacharacters rather than "level
> 1".

I see. Is it just the length limit?

CreateProcess supports 32kb of command line; cmd supports 8kb.  If the
extra 24kb is important, then we can do what you suggest:
shell-quote-argument would also to be further modified to only use level
2 metacharacters when strictly necessary.  Bear in mind that the new
limit would apply only to *shell* commands explicitly, not to subprocess
invocations in general, which would continue to be handled directly by
the code in w32proc.  Besides, I think it's counter-intuitive for a
shell pipeline to stop working merely because it contains more than one
command.

Also, my objection regarding false positives arising from shell
metacharacters embedded in quoted arguments stands: if users do rely on
the successful execution of long, simple shell command lines, these
commands should not break merely because they contain *quoted* shell
metacharacters.  We could have cmdproxy distinguish between quoted and
unquoted metacharacters, but at that point, we could just add
level-2-dequoting as well and solve the problem that way.