bug#15334: Fwd: bug#15334: 24.3; shell-quote-argument not considering non-ascii paths

[Haoyang Xu <snakehsu@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

On Wed, Sep 11, 2013 at 4:11 PM, Andreas Schwab <schwab@suse.de> wrote:

> Haoyang Xu <snakehsu@gmail.com> writes:
>
> > A quick look of the function in question shows that it just escapes all
> > non-ASCII characters, and the escaped Chinese characters cannot be
> > correctly recognized by either bash or zsh.
>
> How does it fail?  Quoting a non-special character should be a no-op to
> the shell (it will just ignore the quote).
>
You are absolutely right. The problem is, shell-quote-argument is trying to
escape characters that are [^-0-9a-zA-Z_./\n] with \\\&, double escape
character, thanks to this part of the function, I think:

(t
    (if (equal argument "")
        "''"
      ;; Quote everything except POSIX filename characters.
      ;; This should be safe enough even for really weird shells.
      (replace-regexp-in-string
       "\n" "'\n'"
       (replace-regexp-in-string "[^-0-9a-zA-Z_./\n]" "\\\\\\&" argument))))
   ))

Although this works for whitespaces and maybe some other characters (and I
don't know why), the resulted string will have _two_ escape characters in
front of every Chinese character. The shell gets this string, and thinks
every Chinese character have one unescaped \ in front of them as part of
the file name, causing a no such file error, it's just like I write my
command as following:

  $ ls ~/Dropbox/Office\ Work/\\参\\考\\资\\料/
  ls: /Users/snakehsu/Dropbox/Office Work/\参\考\资\料/: No such file or
directory

I believe the developers have reasons to write the replace statement like
this, but it does cause problem for a lot of file names.

Haoyang

>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>

[-- Attachment #2: Type: text/html, Size: 3127 bytes --]