GNU bug report logs - #29189
25.3; Dired does not work with binary filenames

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: handa <at> gnu.org, 29189 <at> debbugs.gnu.org, schwab <at> suse.de, vianchielfaura <at> gmail.com
Subject: bug#29189: 25.3; Dired does not work with binary filenames
Date: Sat, 06 Jan 2018 18:04:56 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: handa <at> gnu.org,  vianchielfaura <at> gmail.com,  29189-don <at> debbugs.gnu.org,  schwab <at> suse.de
> Date: Sat, 06 Jan 2018 10:20:38 -0500
> 
> > Situations where file names are not valid byte sequences for the
> > locale's codeset are rare.
> 
> Hmm... then I think I have misunderstood something: why doesn't this
> problem show up with a valid name like "λ" ?

Because "λ" will be inserted by 'ls' as a valid UTF-8 sequence of raw
bytes, and will be correctly decoded.  By contrast, \265 is not a
valid UTF-8 sequence, so we need it to produce a string of a single
raw byte.

> >> I'd also be tempted to additionally signal an error if a non-byte
> >> (i.e. a char that's neither ASCII nor eight-bit-byte) is found since
> >> "decoding" in that case is meaningless.
> > I don't think I understand.  A given byte sequence can either
> > represent a decodable character or be a raw byte.  What third
> > possibility did you have in mind?
> 
> If the input is from a multibyte text, the input is not a byte sequence
> but a character sequence, so the third possibility is to have a non-byte
> in those characters.

Input that is from multibyte text can include raw bytes in their
multibyte representation.  What is a "non-byte"?

Previous Next

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