Re: shell-quote-argument and multibyte

[Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de>]

Hi,


Kenichi Handa <handa@m17n.org> 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
shell-quote-argument.

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
		       buffer-file-name
		       (or file-name-coding-system
			   default-file-name-coding-system))))
	(call-process "antiword" nil t nil "-m" "UTF-8.txt"
		      filename))

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


so long, benny