#687699 xterm: screen output is cut off

Package:
xterm
Source:
xterm
Description:
X terminal emulator
Submitter:
Harald Dunkel
Date:
2019-10-10 16:36:05 UTC
Severity:
normal
#687699#5
Date:
2012-09-15 09:50:09 UTC
From:
To:
If I use pbuilder to build a package within an xterm, then
the screen output gets cut off when ca-certificates-java is
set up.

Attached you can find a sample. In my xterm I get

	% zcat x.gz | wc -l
	3
	% zcat x.gz
	Adding debian:EBG_Elektronik_Sertifika_Hizmet_SaÄ%

If I run the zcat on the console, then I see all 3 lines.


Regards

Harri
#687699#10
Date:
2012-09-15 13:55:35 UTC
From:
To:
	"screen output is cut off"

Harri
#687699#17
Date:
2012-09-15 20:44:13 UTC
From:
To:
For the record, the trailing '%' is printed by zsh (it does that when
the output is not properly newline-terminated), and the problem
apparently only happens in non-UTF-8 locales.

Cheers,
       Sven
#687699#22
Date:
2012-09-16 00:21:11 UTC
From:
To:
Harald did not mention which locales were used (but the 0x9f byte interpreted
in a non-UTF-8 locale will do what is described here).  You may find it helpful
to set the brokenStringTerm resource (doing that would only lose part of the
text).  Better solution would be to use consistent encoding...
#687699#27
Date:
2012-09-18 06:19:29 UTC
From:
To:
A am using C on the shell:

% env | egrep LANG\|LC
LC_ALL=C
LANG=C

The ctrl-right-mouse-button memu shows no mark at
utf-encoding and ut-font, either.

I do not see what pbuilder uses inside, but should this
matter? Any guess about the used locale might be wrong.
I don't expect xterm to output _everything_. It just
shouldn't refuse to output 7bit ASCII.


Regards
Harri
#687699#32
Date:
2012-09-18 08:43:18 UTC
From:
To:
However, your example isn't 7bit ASCII.  It contains 8 non-ASCII bytes
(all from the 128-255 range).

One of those bytes is 0x9f, which happens to be a C1 control character.

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.
#687699#37
Date:
2012-09-21 17:06:09 UTC
From:
To:
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.

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 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?


Regards

Harri
#687699#42
Date:
2012-09-21 22:24:17 UTC
From:
To:
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...

yes (that on the other hand seems to be a bug ;-)