Date: Sat, 27 Nov 2004 09:07:54 +0000 From: Brian Candler <B.Candler@pobox.com> To: Edwin Groothuis <edwin@mavetju.org>, freebsd-stable@freebsd.org Subject: Re: Bug in xterm? Message-ID: <20041127090754.GB730@uk.tiscali.com> In-Reply-To: <20041127005215.GA1108@k7.mavetju> References: <20041126140751.GA1996@uk.tiscali.com> <20041127005215.GA1108@k7.mavetju>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 27, 2004 at 11:52:15AM +1100, Edwin Groothuis wrote:
> [~] edwin@k7>perl -mDigest::MD5 -e 'print pack("H*",Digest::MD5::md5("test"))' | hexdump -C
> 00000000 9f 4d f1 3c ae 73 67 46 |.M.<.sgF|
>
> This shows that it outputs some high-ascii data, which causes the
> xterm to stop output. If you do "echo hi > /tmp/aaa" while in this
> state (be alert for typos), you see that it still accepts commands,
> but doesn't show them anymore.
Thanks. I got a nice analysis off-list:
--------------------------------------------------------------------------
>$ perl -mDigest::MD5 -e 'print pack("H*",Digest::MD5::md5("test"))' >ert
>$ wc ert
> 0 1 8 ert
>$ hexdump -C ert
>00000000 9f 4d f1 3c ae 73 67 46 |.M.<.sgF|
>00000008
>$ cat ert
>
>At this point it hangs; sending ^Q doesn't help. But if you press cursor-up
>a few times it comes back to life.
>
>It must be a strange escape sequence if typing characters and hitting Return
>lots of times is not enough to bring it back to life. I suppose it's
>technically not an escape sequence, since it doesn't include 0x1B :-)
0x9f is APC - which begins a string. Technically it's only terminated by
a ST (0x9c or ESC followed by backslash), but xterm also accepts a BEL,
which may be what's emitted when you do a few uparrows (getting an error
response from the shell). There's also a resource setting to work around
some Linux junk (hardcoded applications with malformed sequences) that
can make it terminate on a carriage return. But generally, it would look
as if it's hung.
(A soft-reset would fix the problem with less damage to your session).
Oddly, a real vt220 would do the same thing, but neither has any use for
the content of the string.
--------------------------------------------------------------------------
I guess I wasn't expecting any escape sequence which consumed an infinite
number of characters - and presumably also, Konsole implements a different
terminal emulation (or implements vt220 wrongly).
Cheers,
Brian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041127090754.GB730>