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 #176 received at 4157 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
Cc: stefan <at> marxist.se, monnier <at> iro.umontreal.ca, 4157 <at> debbugs.gnu.org
Subject: Re: bug#4157: 23.1.50; faulty character characterisation for
 ä
Date: Thu, 10 Oct 2019 21:57:58 +0300

> From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
> Date: Thu, 10 Oct 2019 20:33:56 +0200
> Cc: Stefan Kangas <stefan <at> marxist.se>,
>  monnier <at> iro.umontreal.ca,
>  4157 <at> debbugs.gnu.org
> 
> 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.

Previous Next

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