Am 10.08.2016 um 16:51 schrieb Pádraig Brady: > On 10/08/16 15:21, Peter Ludikovsky wrote: >> Package: coreutils >> Version: 8.23-4 >> Severity: normal >> >> Dear Maintainer, >> >> This came up due to a posting on debian-user-german [1]. Apparently >> certain Unicode characters, at least LEFT-TO-RIGHT EMBEDDING [2] and >> RIGHT-TO-LEFT EMBEDDING [3] do not trigger the escape code display for >> ls with the -b option. >> >> An example script is attached, output: >> >> $ bash unicode_bidir_test.sh >> + touch LTR >> + touch RTL >> + /bin/ls -l >> total 4 >> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 LTR >> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 RTL >> -rw-r--r--. 1 peter peter 148 Aug 10 14:00 unicode_bidir_test.sh >> + /bin/ls -lb >> total 4 >> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 LTR >> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 RTL >> -rw-r--r--. 1 peter peter 148 Aug 10 14:00 unicode_bidir_test.sh >> + /bin/ls -lb LTR >> /bin/ls: cannot access LTR: No such file or directory >> + /bin/ls -lb LTR >> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 LTR >> + /bin/ls -lb RTL >> /bin/ls: cannot access RTL: No such file or directory >> + /bin/ls -lb RTL >> -rw-r--r--. 1 peter peter 0 Aug 10 14:00 RTL >> >> The expected output would be that those characters be shown, as they are >> relevant when accessing a file on the command line. >> >> [1] https://lists.debian.org/debian-user-german/2016/08/msg00049.html >> [2] http://www.fileformat.info/info/unicode/char/202a/index.htm >> [3] http://www.fileformat.info/info/unicode/char/202b/index.htm >> >> -- System Information: >> Debian Release: 8.5 >> APT prefers stable-updates >> APT policy: (500, 'stable-updates'), (500, 'stable') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) >> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> >> Versions of packages coreutils depends on: >> ii libacl1 2.2.52-2 >> ii libattr1 1:2.4.47-2 >> ii libc6 2.19-18+deb8u4 >> ii libselinux1 2.3-2 >> >> coreutils recommends no packages. >> >> coreutils suggests no packages. >> >> -- no debconf information > > Is your locale really "C" ? > With mine set to "C" I get: > > $ LANG=C ls -l > -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ???LTR > -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ???RTL > > $ LANG=C ls -lb > -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 \342\200\252LTR > -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 \342\200\253RTL > > > With the new quoting in version 8.25 you'll get a directly > copy and pasteable representation like: > > $ LANG=C ~/git/coreutils/src/ls -l > -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ''$'\342\200\252''LTR' > -rw-rw-r--. 1 padraig padraig 0 Aug 10 15:43 ''$'\342\200\253''RTL' > > > I'll need to experiment a bit with non "C" locale handling, > and with various terminals, to see how best to handle this case. > > thanks, > Pádraig >
Not really, I haven't set any locale on my servers intentionally. Or
rather, left it at the "POSIX"(?) default during d-i.
$ localectl status
System Locale: n/a
VC Keymap: n/a
X11 Layout: de
X11 Model: pc105
X11 Variant: nodeadkeys
$ cat /etc/default/locale
#LANG="C"
$ env | grep LANG
$ env | grep LC_
$
With both LC_ALL=C and LANG=C it shows at least some indication that
there are other characters. But why not when no explicit locale has been
set?
Regards,
/peter
signature.asc
Description: OpenPGP digital signature

