On Fri, Sep 21, 2012 at 07:06:09PM +0200, Harald Dunkel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/18/12 10:43, Thomas Dickey wrote: > > > > However, your example isn't 7bit ASCII. It contains 8 non-ASCII bytes (all from the 128-255 range). > > > > Sure. The problem is not that the 8bit chars are not shown, but > that xterm refuses to output _anything_ after the "unwanted" 8bit > chars, even if the rest is pure 7bit ASCII. > > > One of those bytes is 0x9f, which happens to be a C1 control character. > > > > Obviously xterm changes an internal state when this control char > has to be printed. Is the rest of the text "illegal" in this new > state? It's buffered until the string-terminator, then xterm decides what to do with the result. Likewise, you would get the same behavior with the 8-bit version of OSC (setting title for instance). Not everyone wants the behavior (notwithstanding its accuracy). So I added the -k8 option... > > xterm has an option allowing you to suppress this behavior: > > > > -k8 This option sets the allowC1Printable resource. When allowC1Printable is set, xterm overrides the mapping of C1 con??? trol characters (code 128-159) to treat them as printable. > > > > but the 0x9f would not produce output in this case unless your font happened to be one of the less-used ones that provides a glyph in that position. > > > > Of course I tried: Seems to work. > > It also works, if I set and immediately unset the "UTF-8 Encoding" > mode in the Ctrl-RButton menu, before I run "zcat x.gz". This is > still weird. Can you reproduce this? yes (that on the other hand seems to be a bug ;-) -- Thomas E. Dickey <dickey@invisible-island.net> http://invisible-island.net ftp://invisible-island.net
Attachment:
signature.asc
Description: Digital signature