[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29189: 25.3; Dired does not work with binary filenames
From: |
Eli Zaretskii |
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@iro.umontreal.ca>
> Cc: handa@gnu.org, vianchielfaura@gmail.com, 29189-don@debbugs.gnu.org,
> schwab@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"?