Bug#721978: xterm: "ls -al /etc/ssl/certs" causes xterm to stop
On Fri, Sep 06, 2013 at 08:14:40PM -0400, Thomas Dickey wrote:
> 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
Thanks again.
It seems to me that two work arounds are OK for me.
xterm -en UTF-8
or
run uxterm instead of xterm
So, I think there is no bug, only behavior that I did not expect.
Thanks for all of your help.
I hope some of this will be useful to someone else.
John
--
John Moyer (KC5GSX)
mailto:jrm@rsok.com
http://www.RSOK.com/~jrm/
Reply to: