GNOME Bugzilla – Bug 705985
gnome-terminal overrides colors set through xterm escape sequences in shell startup
Last modified: 2014-04-06 18:21:24 UTC
Using any scripts which output xterm control sequences to change terminal colors work when manually run in an existing terminal, but don't when placed in a shell startup script (e.g. .bashrc), I guess due to gnome-terminal setting its own colors after the scripts run, overriding the changes. I am specifically trying to use some of the colors scripts from here: https://github.com/chriskempson/base16-shell I can confirm the commands are actually being run and working because: a) Running the script manually in the shell prompt works b) Colors show up on startup when using the Drop Down Terminal GNOME Shell extension (https://extensions.gnome.org/extension/442/drop-down-terminal/) c) Other startup commands like custom prompts work fine. But placing them in .bashrc results in a terminal with the default colors (which I have not changed from the Fedora 19 standard configs). Relevant program versions: GNOME Terminal 3.8.4 GNU bash, version 4.2.45(1)-release (x86_64-redhat-linux-gnu) Fedora 19 x86-64
I just realized the colors are overriden every time I Alt-Tab from gnome-terminal as well. I don't know if that is intended behavior, but if it is, is there a way to disable it? I'd really rather use a single method for coloring all my terminals.
I was about to report the same, with g-t 3.10 and vte 0.34.8. I'm sure this is not the desired behavior. echo -e '\e[32mGreen is now blue\e[0m\e]4;2;blue\a' It's blue, but turns green on focus out. This way the feature of setting a custom palette is pretty much unusable. I guess vte handles color changes via escape sequences and via API calls in the same way, they override each other's effects. In my opinion the correct behavior would be to have a hierarchy where a color set by the API is weaker, while the color set by escapes is stronger. A color set by an escape code shouldn't be overwritten by a subsequent API call. A terminal reset should perhaps clear the strong values set by escape codes, and hence set the latest value requested via API.
The problem here is that with 'use colours from system theme', the focus-out changes the colours and thus overrides the colours set from the terminal app. Comment 2 has the right solution for this.
FYI: cursor color has the same problem (echo -e '\e]12;pink\a')
@Christian Persch Disabling the use colors from system option doesn't help, custom colors still get overridden.
Discussions in bug 567444 might be relevant.
It's even worse with the cursor color (comment 4). Change it to pink, focus out, it gets reverted to black, but now it's pitch black blocking out the character it's standing on, rather than inverting it.
*** Bug 700775 has been marked as a duplicate of this bug. ***
Created attachment 256841 [details] [review] Fix Here's a fix. Tested only with escape sequences and g-t settings, which doesn't include unsetting the cursor color. Most of the code is pretty straightforward. Colors of the 256 palette is simple because the default is always a valid color. Highlight color is simple because there's no escape seqeunce to set it. The cursor color is the only complicated one-off code. It's complicated because: - the default is not representable as a regular color - there's an API to set the cursor color, or to revert it to the default - there's an escape sequence to set the cursor color, but there's no escape code to unset it. - the escape code is supposed to be stronger than the api call. Hence restoring the default should only happen if the value was set via api, not via escape. For sake of simplicity, I don't maintain a separate flag for every index and color source whether it was set from there, I only have the two colors (default and actual) per index. Escape sequenes update the actual color only. API calls update the default, or both if the old two values were identical. This means that if an escape sets the exact same color as was set by the API then a further API call will change it. A more proper but more complex infrastructure would IMO probably be an overkill, complicating everything, for the sake of making this special case and handling the cursor color easier and nicer. I didn't think it was worth it.
Fixed on vte-0-36.