GNU bug report logs - #18037
24.3; term.el cannot track non-ascii directories

Previous Next

Package: emacs;

Reported by: Johan Claesson <johanclaesson <at> bredband.net>

Date: Wed, 16 Jul 2014 18:11:02 UTC

Severity: normal

Found in version 24.3

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Johan Claesson <johanclaesson <at> bredband.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18037 <at> debbugs.gnu.org
Subject: bug#18037: 24.3; term.el cannot track non-ascii directories
Date: Fri, 14 Nov 2014 17:37:13 +0100

Hi,

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

Regards,

/Johan




Johan Claesson <johanclaesson <at> 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 <at> gnu.org> writes:
>
>>> From: Johan Claesson <johanclaesson <at> 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.




This bug report was last modified 10 years and 194 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.