How to get a human-readable (e.g. RGB) value from `\e]11;?\a`?

Question

The string \e]11;?\a presumably yields the current terminal's background color, but I have not found a way to use this information to get the color in a human-readable (e.g. RGB) format.

I did try (cluelessly)

print -P '\e]11;?\a'

but it produces nothing, or at least nothing visible.

BTW, I'm aware of xtermcontrol --get-bg, but when I run it on the terminal I'm working on, I get the error:

xtermcontrol: --get-bg is unsupported or disallowed by this terminal. \
See also, TROUBLESHOOTING section of xtermcontrol(1) manpage.

(The referred-to TROUBLESHOOTING section did not provide any work-around.)

BTW, I have deliberately omitted details about the terminal I'm using because I'm hoping to find a general solution, rather than one that works only for a specific terminal.

Answer 1

There are a couple of fundamental problems with this question:

1. For this to result in a general solution, the command would have to be supported by ANSI X3.64, the base standard for all modern terminals, but as far as I can tell, that is not an ANSI command.

   I'm uncertain because I don't have a copy of that standard, I can't find one online, and ANSI won't sell me one. All I can find online are bastardized "references". As I describe elsewhere, while X3.64 is the root standard of all common modern terminals, that observation is a bit like pointing out that dogs are descended from wolves: studying wolves to learn about dogs puts severe limitations on the scope of things you can learn.

   The best resource I've found is the XTerm Control Sequences reference, maintained by the current xterm maintainer. But, this is not a normative standard, it merely describes what one common program does. Many programs are derived from the xterm source code, but like dogs from wolves, many have diverged significantly.

   I suspect you'd find, if you chased it down, that this command was introduced by xterm as an extension to ANSI X3.64, and your target terminal doesn't support that particular xterm extension, which is why xtermcontrol fails.

2. Even if your particular set of terminals all give a reply to this command, I don't see from the above-referenced document that you're going to get an RGB value. You may well get a color name instead.

   (This is the sort of detail we expect a normative standard to nail down, which is often overlooked in functional description documents.)

   Also, beware that even if you do get an R;G;B reply, the answer can vary. If you set your color using the older ANSI X3.64 color codes, there is no standard saying which RGB color they map to; indeed, every xterm family terminal program I've ever used gives a way to change the RGB colors used for the ANSI color codes. Also, you can change these values on the fly in some terminal programs, so that two program runs separated by a third-party program run might give different answers because the color scheme is now different.

There is another answer in the SE network that does roughly the same thing your print statement does, but like your command, the other answer's echo command gets no response from OS X's Terminal, which claims to be an xterm-256color terminal. That means the solution doesn't even work for all xterm family terminals.

I've written a more robust C program which diagnoses the error if it happens, and if not, shows the return values in printable form. You might find it to be a more suitable base for extension than shell commands:

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

char reply[40];
size_t nr;

void timeout(int sn)
{
    if (nr > 0) {
        for (size_t i = 0; i < nr; ++i) {
            printf("Got char %d\n", reply[i]);
        }

        if (!sn) puts("WARNING: Buffer filled!");
    }
    else {
        puts("No reply from terminal.");
    }

    exit(0);
}

int main(void)
{
    signal(SIGALRM, timeout);
    alarm(1);
    printf("\e]11;?\a");

    for (nr = 0; nr < sizeof(reply); ++nr) {
        reply[nr] = getchar();
    }

    timeout(0);   /* buffer filled before alarm() timer went off! */
    return 0;
}

Answer 2

First, it is unlikely that some alternative method (other than responses to control sequences) could be the basis of "a general solution" as requested by the OP, since the property sought is not (for example) amenable to methods using the window properties.

Next, this is an example of control sequences which are implemented in xterm but not generally available. The developer of xtermcontrol is aware of this. His page discusses xterm control sequences, comments that there are many of them (a plethora), and mentions that OSX Terminal.app supports some of them.

The error message reported by OP is certainly clear enough. The unnamed program on which OP attempted to run xtermcontrol does not support the feature. Likely enough, it does not support a comparable feature which could be used instead.

In practice, a majority of xterm's control sequences are not implemented in other terminals, regardless of their developer's use of "xterm" for the terminal description. See for example the xterm FAQ Comparing versions, by counting controls, and the ncurses FAQ Why not just use TERM set to "xterm"? (noting that "derived from the xterm source code" can be interpreted in more than one way).

The terminals of (perhaps) more interest to OP have no useful documentation on which control sequences they implement. So the only way to find how "general" a solution you have is to exhaustively test it. That seems not very general.

The top-voted Super User answer is the method used by xtermcontrol. (The downvoted xrdb answer will not give you the current color settings from xterm, only its initial values — perhaps not even that.)