bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#13589: 24.2.92; wrongly escaped call-process arguments
Date: Wed, 30 Jan 2013 19:55:20 +0200

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]