It looks like xterm supports some more non-standard color sequences, see http://invisible-island.net/xterm/ctlseqs/ctlseqs.html OSC = "\e]" or 1B 5D ST = "\e\\" or 1B 5C Sequences like "OSC 4;{...} ST" are not handled. Some of the xterm OSC sequences are handled, but ST is not. Even if the new color sequences aren't to be supported, the ST should be but instead results in "Undecodable sequence: \001b(hex)\\" on stdout. I have a file that reportedly demonstrates the use of these codes.
Created attachment 42679 [details] C demo to show usage of xterms RGB mode
you have to export TERM=xterm-256color before usage (tput colors should report 256 color mode then)
it seem you guys have fear of the evil data buffer in my C program. i therefore created a C++ application which can display any image on the xterm console, but not on the "K"onsole. here it is : https://github.com/rofl0r/conpix it's pretty simple, basically just a class ConsoleWindow and a launcher, and 2 or 3 mini-helper classes. you can see from a quick glance that the code won't harm you.
the problem with Konsole here is that it allows 256 colors to be picked, but only if taken from a linear palette (the one used by the famous perl program http://www.frexx.de/xterm-256-notes/data/256colors2.pl ). however if you pick other colors by RGB values with init_color, that are not in this linear set, it fails. my guess is that the author only used the above perl script for tests.
*** Bug 173555 has been marked as a duplicate of this bug. ***
maybe related with bug #231405.
OSC 4, 10 and 11 (and probably a few more in the 12-19 range for cursor and highlight fg/bg, see http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Operating-System-Commands) would be useful for xtermcontrol(1) to work, e.g. to be able to query the default fg/bg colors. See also bug 336849. Note that these should be implemented along with their 104, 110, 111 etc. counterparts that reset these colors. In VTE (gnome-terminal and friends) the implementation used to take escape sequences (OSC 4, 10...) and API (user changing the palette in the prefs dialog) equally. This led to confusions and unexpected behavior when e.g. opening and closing the prefs (without changing anything) would overwrite the effect of a previous OSC 4. So we ended up fixing this (in version 0.36) by introducing two levels. For each slot (256 for the palette of OSC 4, plus a few one-offs like default foreground and background) there's the value set via API (e.g. prefs dialog) which always contains a color, and there's the optional value set via OSC 4 (this can be undefined, and actually the OSC hundred's clear this). If the OSC slot is defined for a particular color entry then that one is used, otherwise we fallback to the API. In other words, escape sequences have precedence.
*** Bug 432718 has been marked as a duplicate of this bug. ***