On Fri, Sep 06, 2013 at 06:30:03PM -0500, John Moyer wrote: > On Fri, Sep 06, 2013 at 06:10:33PM -0400, Thomas Dickey wrote: > > On Fri, Sep 06, 2013 at 07:53:40AM -0500, John Moyer wrote: > > > Package: xterm > > > Version: 278-4 > > > Severity: normal > > > > * What led up to the situation? > > > ls -al /etc/ssl/certs > > > start xterm on local host. ssh to remote host running Wheezy. ls > > > There is no problem if I do this on local host, so maybe ther problem is > > > some combination of ssh and xterm. strace on ssh shows it is in read(). > > > > ls -al /etc/ssl/certs | cat -v > > > behaves as expected. > > > > > > /etc/ssl/certs/T*Sertifika* is the file name that causes problems. There is no > > > problem with the Xfce desktop terminal except that the filename does not > > > display correctly. > > > > > > 00000000 2f 65 74 63 2f 73 73 6c 2f 63 65 72 74 73 2f 54 /etc/ssl/certs/T > > > 00000010 c3 9c 42 c4 b0 54 41 4b 5f 55 45 4b 41 45 5f 4b ..B..TAK_UEKAE_K > > > 00000020 c3 b6 6b 5f 53 65 72 74 69 66 69 6b 61 5f 48 69 ..k_Sertifika_Hi > > > 00000030 7a 6d 65 74 5f 53 61 c4 9f 6c 61 79 c4 b1 63 c4 zmet_Sa..lay..c. > > > 00000040 b1 73 c4 b1 5f 2d 5f 53 c3 bc 72 c3 bc 6d 5f 33 .s.._-_S..r..m_3 > > > 00000050 2e 70 65 6d 0a .pem. > > > > > > lrwxrwxrwx 1 root root 104 May 17 19:11 T##B##TAK_UEKAE_K##k_Sertifika_Hizmet_Sa##lay##c##s##_-_S##r##m_3.pem -> /usr/share/ca-certificates/mozilla/T##B##TAK_UEKAE_K##k_Sertifika_Hizmet_Sa##lay##c##s##_-_S##r##m_3.crt > > > > The string is encoded with UTF-8, but according to the summary, your > > locale is C (POSIX). The 9f begins a string which is not terminated > > (see ctlseqs.ms): > > > > ESC _ > > Application Program Command (APC is 0x9f). > > > > Also see the discussion of brokenStringTerm in the manpage. > > > > (This is not a bug in xterm, by the way). > > > > > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) > > > > -- > > Thomas E. Dickey <dickey@invisible-island.net> > > http://invisible-island.net > > ftp://invisible-island.net > > Thank you for your reply. > > Should I will try setting brokenStringTerm to true in an X resources file. Setting that helps - but then you can run into the occasional problem where you're wondering why part of the output is missing. You would miss text between the start of the control and the next newline. > Should I use a different locale? I think the problem is with the locale. xterm's locale resource is normally configured in Debian so that running it in a UTF-8 locale will do something reasonable. But connecting via ssh sounds as if it is using POSIX locale, ignoring your starting point. Reflecting on this, it seems that ssh generally doesn't pass-through the locale settings, though it usually passes TERM - a possible reason for that is because ssh's developers use OpenBSD which doesn't do anything useful with locales... Instead, we get various systems just setting the locale. There are workarounds, but most are nuisances to setup (see for example, ssh_config's SendEnv and AcceptEnv settings). If you have a small number of local/remote machines to configure, that is the place to try first. You can of course override the locale in a shell. (I work-around a different way - connecting to machines with X forwarding, and running uxterm when a remote machine has UTF-8 locale turned on - it also has the advantage that I can run screen in the uxterm or xterm). > Is this a bug in ssh? Was it ssh that was stopping? ssh contibutes to the problem, but reporting a bug there is a waste of time. > Is this a Mozilla bug, using an improper file name? UTF-8 filenames are legal :-) ls doesn't check locale of course (I suppose it's hardcoded in that way just like its color support). > Should I report this bug elsewhere? I think you came to the right place :-) -- Thomas E. Dickey <dickey@invisible-island.net> http://invisible-island.net ftp://invisible-island.net
Attachment:
signature.asc
Description: Digital signature