[Top][All Lists]

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

Re: shell-quote-argument and multibyte

From: Benjamin Riefenstahl
Subject: Re: shell-quote-argument and multibyte
Date: 17 Apr 2003 15:54:07 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Kenichi Handa <address@hidden> writes:
> By default, process arguements (including the filename in the above
> case) are encoded by:
>     (cdr default-process-coding-system)
> And usually, it is the same as default-file-name-coding-system.
> So, if it doesn't work, it means that something is wrong in setting
> up coding systems on Windows.

Thanks for the clarification. 

> And, [encode-coding-string] shouldn't be done in
> shell-quote-argument.  Such an encoding should be done only for file
> names.

I understood that file names were the actual concern of the OP.  But
you are right, the encoding should probably be done outside of

Still the connections are not entirely clear to me.  I routinely
configure tools so that they output UTF-8, so the coding system for
I/O should be UTF-8.  But that doesn't change the fact that the file
name encoding is latin-1.

Commands like shell-quote-argument, call-process or
shell-command-to-string don't know which of their arguments are file
names.  While most of the command line arguments that are not file
names will not have non-ASCII characters (options), there are of
course arguments that are free text, like e.g. CVS log messages or
verbatim scripts.

That does mean that, to do the right thing, I will currently have to
encode the file names myself, right?  Like e.g. in this fragment,
which I use for reading Word documents with an external tool:

      (let ((coding-system-for-read 'utf-8)
            (filename (encode-coding-string
                       (or file-name-coding-system
        (call-process "antiword" nil t nil "-m" "UTF-8.txt"

Or is there a way to simplify this kind of thing?

so long, benny

reply via email to

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