GNU bug report logs - #4157
[macOS/HFS] dired doesn't decode ls output when it uses different encoding for filename vs date

Previous Next

Package: emacs;

Reported by: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>

Date: Sun, 16 Aug 2009 02:25:05 UTC

Severity: minor

Tags: notabug

Found in versions 27.0.50, 23.1.50

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log

Message #132 received at 4157 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Peter_Dyballa <at> freenet.de, monnier <at> iro.umontreal.ca, 4157 <at> debbugs.gnu.org
Subject: Re: bug#4157: 23.1.50;
 faulty character characterisation for รค
Date: Wed, 09 Oct 2019 21:48:54 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 9 Oct 2019 16:29:43 +0200
> Cc: Peter Dyballa <Peter_Dyballa <at> freenet.de>, 4157 <at> debbugs.gnu.org
> 
> > "correct" doesn't really tell me what you see, but I see what you mean.
> >
> >> "composed characters," it's a problem with the file's  month date. In the
> >
> > So my guess was right: ls's output uses utf-8 for the filenames, but
> > latin-1 for the date, which is why it's difficult for dired to do the
> > right thing (it's not impossible, of course, but it's more work and
> > dired is currently not setup for that).
> 
> Ten years later, I can verify that this is still an issue on current
> master running on macOS 10.13.  I think Stefan Monnier is spot on
> above.

Maybe we should switch macOS to using ls-lisp.el?
This bug report was last modified 5 years and 189 days ago.

Previous Next

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