On Tue, Feb 20, 2024 at 07:41:42PM +0100, Sven Joachim wrote:
On Tue, Feb 20, 2024 at 04:15:30PM +0800, Paul Wise wrote:
$ tput sgr0 | hd
00000000 1b 28 42 1b 5b 6d |.(B.[m|
Here's the culprit. The code you asked for is "\e[0m" -- shortenable to non-canonical but valid "\e[m", which is the second half of tput's output.
What you did not ask for, is "\e(B", which is not allowed in UTF-8 mode, and in non-Unicode world would switch to an ancient "US" charset.
Maybe that is true for the Linux console, but we are talking about xterm here.
It's not a property of the terminal, but of ECMA-35.
And what "xterm" are you talking about? tput has no way to know the
terminal on the other side, as the string TERM=xterm (and
TERM=xterm-256color) applies to over a hundred different terminals using
tens of different code bases. And you can't even blame their authors, as:
* most Unices stopped maintaining their terminfo databases (eg. Solaris
still hasn't learned about TERM=linux. Solaris is no longer relevant now
but was relevant for most of that time frame.)
* even if the databases were maintained, a new terminal would become useful
only several years after it gets released (as the terminfo entry would
need to be deployed on every box you might possibly ssh into, with
failure mode being complete breakage of any terminfo-using program)
Thus, putting aside historic terminals, there are only three TERM values:
* linux
* rxvt (used by its derivatives like aterm)
* xterm (everything else)
(Skipping decorations like -256color which most programs hard-code anyway.
I thus had to implement 256 color fallbacks in the kernel in 2016; it seems that eg. 24-bit color is moving the same way.)
Putting aside arguments if this code is allowed or not (eg. the author of Putty has strong feelings on the matter), it's very clearly not what you asked for, thus the real bug is on tput's side.
Thus:
"tput sgr0" should produce sgr0, not setusg0 sgr0.
It does of course produce sgr0, i.e. it emits whatever escape sequence $TERM's terminfo entry declares as sgr0. In the case of xterm-256color, sgr0=\E(B\E[m.
And it's that entry what's wrong. sgr0 means "\e[0m" (or "\e[m"); see
eg. docs for real xterm:
https://www.xfree86.org/current/ctlseqs.html
The reason for including \E(B here is that sgr0 should cancel the
effects of a previous smacs (start alternate character set) sequence and
thus includes the rmacs (end alternate character set) escape sequence.
Then it combines two completely different concepts in one label. SGR is
for character attributes, G0/G1 are for encoding.
People are relying on this behavior, see #595484 for instance.
Seems like an XKCD 1172 case.
Closing the bug, because everything works as intended.
...
Well, I'm not going to fight a BTS war, but I don't agree with your
decision.
I'll work around this misbehaviour (as it's no extra work for me: I need
to handle legitimately occuring G0/G1 changes anyway). Still, it is a bug
even if its severity is negligible: thanks to PuTTY's author's stubborness
no maintained software uses G0/G1 anymore.
Thus, the only real fallout is bloating terminal output. It's still too
slow on serial links or inferior terminals (I felt bad about Scaleway's
web console just hours ago); saving three bytes per sgr0 is not much but
it is a very frequently used sequence.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄⠀⠀⠀⠀
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)