#687699 xterm: screen output is cut off

Package:
xterm
Source:
xterm
Description:
X terminal emulator
Submitter:
Harald Dunkel
Date:
2026-09-01 00:37:02 UTC
Severity:
normal
Tags:
#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 ;-)
#687699#53
Date:
2026-08-28 18:13:55 UTC
From:
To:
Thanks for the new xterm 411 release, but I did not notice an
improvement in this regard.  The recipe given by the bug submitter still
stops output in a non-UTF-8 locale.

Cheers,
       Sven
#687699#58
Date:
2026-08-28 18:51:01 UTC
From:
To:
fwiw, my (local) commit comment said:

	the original report was invalid, as I noted in response.  But this
	followup comment showed a problem.  That turns out to be a small fix to
	charproc.c, to allow C1 controls to be interpreted _after_ initializing
	wide characters but _after_ turning UTF-8 mode off again.

	If starting from POSIX locale as OP did, that can be done with the menu.
	Normally (starting from UTF-8 locale) the menu entry is grayed out, but the
	control sequence still works.

	I also verified that this is the case for OpenBSD 7.2, in case Ingo or Matthieu
	questions it.
#687699#63
Date:
2026-08-30 16:07:09 UTC
From:
To:
I am not sure I understand that.  Does "the control sequence" refer to
"ESC % @" which selects the ISO 8859-1 character set?

I have no idea who Ingo or Matthieu are, but whatever.

In any case I consider what happened to the submitters of
#687699/#751757 rather surprising and undesirable and would prefer to
leave the bug open, even if you consider it invalid.  Feel free to tag
it wontfix, though.

Cheers,
       Sven
#687699#68
Date:
2026-08-30 17:28:52 UTC
From:
To:
I'm unsure what you're referring to.  I responded to the bug report,
and pointed out what the expected behavior was.  Keep in mind that
no one responded to my comment about the issue which I noticed and fixed.

"wontfix" is unsuitable, because (a) the report was based on invalid
assumptions, and (b) the report got me to look at it carefully and
see something which should be fixed.

By marking it "wontfix", I expect that nothing has been resolved on
Debian's side.