bug#13589: 24.2.92; wrongly escaped call-process arguments

[Shigeru Fukaya <shigeru.fukaya@gmail.com>]

Thank you for your reply.

Why I used CharNextExA is I can't find such functions for encoded
strings in Emacs.  Possible alternative is to change the quoting
process out of binary to elisp code.  Or provide some hook for it?

And, anyway, could you please initialize 'escape_char', so that we can
safely set `w32-quote-process-args' to nil and do some quoting by
ourselves (using advise or something).

Shigeru

>> From: Shigeru Fukaya <shigeru.fukaya@gmail.com>
>> Date: Thu, 31 Jan 2013 01:36:35 +0900
>> 
>> `call-process' wrongly treats those multibyte characters whose
>> 2nd byte is 0x5c.
>> It is bacause sys_spawnve in w32proc.c does bad quoting process.
>> 
>> Bad example:
>> 
>> (let ((coding-system-for-write 'cp932))
>>   (call-process "sh" nil t nil "-c" "ls d:/tmp/表*"))
>> ls: cannot access d:/tmp/表*: No such file or directory
>> 2
>> 
>> Correct example:
>> 
>> (let ((coding-system-for-write 'cp932))
>>   (call-process "sh" nil t nil "-c" "ls d:/tmp/表*"))
>> d:/tmp/表
>> d:/tmp/表1
>> 
>> d:/tmp/表表:
>> abc
>> 0
>> 
>> I tried fixing it (after w32.c as a reference).
>> Additionally, I set uninitialized `escape_char' to 0.
>
>Thanks for the report and the patch.
>
>Unfortunately, I don't think the solution you suggest is the right
>one.  It is one thing to support only Windows codepages in encoding of
>file names, as w32.c does: after all, that's the limitation of the OS
>APIs we use.  But imposing the same limitation for encoding
>command-line arguments to subprocesses is something entirely
>different.  E.g., consider such trivial example as invoking a speller:
>the encoding used to pass non-ASCII characters on the command line in
>this case might have nothing at all to do with Windows codepages.  We
>can no longer justify not supporting shift_jis in this case, for
>example.  IOW, using CharNextExA here would impose an unreasonably bad
>restriction on how subprocesses can be invoked from Emacs.
>
>In addition, without also fixing cmdproxy, which does similar things,
>this is not going to solve the problem, except in a few select cases.
>E.g., I think it's enough for you to use shell-file-name instead of
>"sh" to have the command be handed to cmdproxy by default, and then
>you'll have the same problem there.
>
>We need a better, less restricted and more thorough solution.  I don't
>yet know which one.
>
>Thanks.