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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>, stefan <at> marxist.se,
 4157 <at> debbugs.gnu.org
Subject: Re: bug#4157: 23.1.50; faulty character characterisation for
 ä
Date: Thu, 10 Oct 2019 17:07:15 -0400

>> Alright, file names in Mac OS X were recorded in a special form of UTF-8,
>> accented characters as two characters. GNU ls outputs the month name
>> correctly, but not the file name, which is still held in UTF-8 and not
>> converted to ISO Latin-9. So it's more of a GNU ls bug.
>
> No, I don't think it is.  No version of 'ls' I know of, including GNU
> 'ls', recodes file names, they just emit the bytestream they find in
> the directory.  The idea is that you create files and display them
> under the same setting of the locale's codeset.  If you change the
> codeset between the time you created the file and the time you display
> it, you are toast.  AFAIK, this happens on any Posix filesystem.

There are different ways to look at the problem and attribute blame
(e.g. since macosx enforces file names to be utf-8 (contrary to POSIX),
`ls` in macosx *could* do the recoding of filenames reliably), but in
any case I think it's clear for me that it's not a bug in Emacs.


        Stefan

Previous Next

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