bug#18037: 24.3; term.el cannot track non-ascii directories

[Johan Claesson <johanclaesson@bredband.net>]

Hi,

This problem is corrected in 24.4.  I think the bug report can be
closed.

Regards,

/Johan




Johan Claesson <johanclaesson@bredband.net> writes:

> Ok, good catch.
>
>
> --- a/term.el	2014-07-16 19:22:09.348823919 +0200
> +++ b/term.el	2014-07-16 21:30:28.272894153 +0200
> @@ -3424,7 +3424,8 @@
>  			   (substring string (1+ first-colon) second-colon))))
>  	   (setq term-pending-frame (cons filename fileline))))
>  	((= (aref string 0) ?/)
> -	 (cd (substring string 1)))
> +	 (cd (decode-coding-string (substring string 1)
> +                                   locale-coding-system)))
>  	;; Allowing the inferior to call functions in Emacs is
>  	;; probably too big a security hole.
>  	;; ((= (aref string 0) ?!)
>
>
>
> Regards,
>
> /Johan
>
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Johan Claesson <johanclaesson@bredband.net>
>>> Date: Wed, 16 Jul 2014 20:09:48 +0200
>>> 
>>> --- a/term.el   2014-07-16 19:22:09.348823919 +0200
>>> +++ b/term.el   2014-07-16 19:25:33.920825786 +0200
>>> @@ -3424,7 +3424,7 @@
>>>                            (substring string (1+ first-colon) second-colon))))
>>>            (setq term-pending-frame (cons filename fileline))))
>>>         ((= (aref string 0) ?/)
>>> -        (cd (substring string 1)))
>>> +        (cd (string-as-multibyte (substring string 1))))
>>>         ;; Allowing the inferior to call functions in Emacs is
>>>         ;; probably too big a security hole.
>>>         ;; ((= (aref string 0) ?!)
>>
>> string-as-multibyte is not right.
>>
>>> (Motivation: in term-exec-1 the coding-system-for-read is set to 'binary
>>> with the following comment:
>>> 
>>>         ;; The process's output contains not just chars but also binary
>>> 	;; escape codes, so we need to see the raw output.  We will have to
>>> 	;; do the decoding by hand on the parts that are made of chars.
>>> 
>>> I think term-command-hook is one place where such decoding is needed.)
>>
>> Indeed; but string-as-multibyte is not the way to decode the string.
>> You need to use decode-coding-string and locale-coding-system.