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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefan <at> marxist.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Peter Dyballa <Peter_Dyballa <at> freenet.de>, 4157 <at> debbugs.gnu.org
Subject: bug#4157: 23.1.50; faulty character characterisation for ä
Date: Wed, 9 Oct 2019 16:29:43 +0200

found 4157 27.0.50
quit

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> Hmm... that looks like a problem in dired: the file names in the output
>>> of `ls' should follow file-name-coding-system, whereas the rest of the
>>> output seem to use locale-coding-system.  Coudl you check if that's
>>> indeed the case:
>>> - create a file from the Finder using accented latin-1
>>> chars, as well as non-latin-1 chars).
>>> - look at it in your dired and tell us what you see.
>> In both locales the *file names* are correct and also detected as containing
>
> "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.

Best regards,
Stefan Kangas

Previous Next

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