bug#15337: 24.3.50; [PATCH] cd to directory name with french accent fail from term/ansi-term

[Thierry Volpiatto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Wed, 11 Sep 2013 13:57:24 +0200
>> 
>> diff --git a/lisp/files.el b/lisp/files.el
>> index f9ff3c9..a27bb06 100644
>> --- a/lisp/files.el
>> +++ b/lisp/files.el
>> @@ -729,7 +729,7 @@ The path separator is colon in GNU and GNU-like systems."
>>      (setq cd-path (or (parse-colon-path (getenv "CDPATH"))
>>                        (list "./"))))
>>    (cd-absolute
>> -   (or (locate-file dir cd-path nil
>> +   (or (locate-file (decode-coding-string dir locale-coding-system) cd-path 
>> nil
>>                      (lambda (f) (and (file-directory-p f) 'dir-ok)))
>>         (error "No such directory found via CDPATH environment variable"))))
>> --8<---------------cut here---------------end--------------->8---
>
> How come cd-path got a value that is a unibyte string?  If it came
> from getenv, then that function explicitly decodes the values.
>
> IOW, please dig deeper and tell where did the unibyte string in
> cd-path come from, because I don't see why would it be TRT to decode
> it where you suggest; perhaps I'm missing something.

I am using emacs -Q here and CDPATH is empty (I don't use it).
(getenv "CDPATH") => nil
env | grep CDPATH => empty too.

cd is working as expected from emacs itself, but when used from term,
the string "~/Téléchargement" is
"/home/thierry/T\303\251l\303\251chargements"
so `file-directory-p' fails on
"/home/thierry/T\303\251l\303\251chargements"
And the CDPATH error is called.

So the patch I send fix the problem but yes maybe the decoding should
occur somewhere in term.el instead when sending the string to `cd'.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997