Re: Bash colour codes

[Koichi Murase]

2021年4月17日(土) 7:48 <pauline-galea@gmx.com>:
>
> Would you know where to find some documentation for that?  I am finding
> it very hard to find details beyond the indexed color mode setting.

There is a complicated history behind these variations of SGR(38) and
SGR(48). I don't know documents describing the history.

----

For terminal control sequences generally, you should first see ECMA-48
https://www.ecma-international.org/publications-and-standards/standards/ecma-48/
[so-called ANSI terminal standard, but actually ECMA-48 / ANSI X3.64
are not the standard only for terminals and also contain many control
sequences unrelated to Unix terminals as well].  For SGR(38) and
SGR(48), ISO 8613-6 (ITU T.416) are referenced from ECMA-48.  You can
find the description on SGR(38) and SGR(48) on page 41 of ITU-T Rec.
T.416 (1993 E) https://www.itu.int/rec/T-REC-T.416-199303-I/en .  The
standard originally defined 38:0...38:5 and 48:0...48:5 for ODA
documents (but not for terminals).  In the standard, the subparameters
of 38 and 48 are supposed to be separated by colons.

SGR(38) and SGR(49) have never been implemented in terminals at that
time, but later, Xterm has first supported the indexed colors (38;5
and 48;5) in xterm#112 (1999) with the "wrong" format \e[38;5;${fg}m
and \e[48;5;${bg}m, where the subparameters are wrongly separated by
semicolons instead of colons.  After that, other terminals followed
Xterm's implementation, and it became a de-facto standard.

I think one of the initiators of RGB colors in terminals is konsole.
Konsole has implemented \e[38;2;${R};${G};${B}m and
\e[48;2;${R};${G};${B}m, but there was another mistake in the
implementation:  konsole has dropped the color space parameter after
"2" which is requested in ISO 8613-6 as
\e[38:2:$colorSpace:$R:$G:$B:...m.  You can read the discussion at
that time in "README.moreColors" of konsole
https://github.com/robertknight/konsole/blob/master/user-doc/README.moreColors
.  It seems konsole has recognized the mistake of Xterm, but clearly,
konsole was also misreading the standard at that time, and they
finally couldn't understand the standard and gave up following the
standard.  This another mistaken control sequence was also followed by
other terminals and became also a de-facto standard.

After that, some terminals have independently pointed out that there
were mistakes in reading the standard.  Now the original implementor
Xterm and some other terminals have supported the standard form of the
colon-separated subparameters and recommends people to shift to the
standard form [You can read the latest version of Xterm "ctlseqs"
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html , in
particular, the section for "CSI Pm m---Character Attributes (SGR)"].
So, now the legacy forms \e[38;5;${index}m and \e[38;2;$R;$G;${B}m are
implemented most widely among terminals, but terminal developers want
to shift to the standard form which is less problematic when a
terminal doesn't support SGR(38:N) / SGR(48:N).  In Terminal WG (the
working group of terminal developers which aims to form a consensus on
terminal behaviors), this RGB-color support is also discussed as a
part of the proposal of the terminal feature identification
https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/8
.  The proposed wording for RGB colors can be found at
https://gitlab.freedesktop.org/terminal-wg/specifications/-/blob/45c1c6c46e0de498064e826f63e1daf3ab400f82/proposals/feature-reporting/index.md#24bit
.

--
Koichi