Red Hat Bugzilla – Bug 849429
Fedora 18 256 color terminal feature
Last modified: 2016-01-04 09:47:40 EST
Created attachment 605480 [details]
script to enable feature
I've attached a small patch to initscripts
enabling the "256 color terminals" Fedora 18 feature.
You should be able to apply using: git am < term256.diff
I tested it with the 25 xterms I could find in Fedora,
with both csh and sh shells, and all xterms are handled
appropriately. Users logging in remotely are not impacted.
For details of the feature see:
Is there any plan to take this patch into account before the F18 Beta release?
Apologies - have been traveling and tied up in other things. This will happen before beta, but not before alpha.
Added in git, with tweaks to the comments suggesting methods of setting SEND256... that don't involve editing the packaged profile.d files.
I checked your amendments at http://git.fedorahosted.org/cgit/initscripts.git/commit/?id=c819f19 which make lots of sense.
I've found a culprit in here.
If I put a self-made .dircolors in my home directory, normally /etc/profile.d/colorls.sh should set it but this is broken in F18.
The reason is that term256.sh is alphabetically after colorls.sh in /etc/profile.d which means that it is executed after colorls.sh which calls "dircolors" from coreutils. dircolors utility fails if $TERM != one of the TERM's written in .dircolors.
And bingo, no colors at all in the terminal.
Rename the file to 00-term256.sh and it's fixed.
This is because the local file doesn't have a current list of colorizable terms, correct?
Drats. I did all my testing with /etc/profile.d/256color.sh
and switched to term256.sh at the last minute :(
I agree that this script should run early,
and renaming to 00-term256.sh would be a good way to do that.
I don't fully understand why Ozan has no colors.
If dircolors is run from colorls.sh, how could term256.sh impact here?
Ozan: Could you please be more specific what's broken on colorls.sh in F18?
Okay I think I couldn't explain the problem in a clear way, here it is:
- There is no problem if you don't put a custom .dircolors/.dir_colors in your $HOME directory.
- Just copy /etc/DIRCOLORS.256color into your $HOME as .dircolors/.dir_colors, open a new shell in gnome-terminal and you'll see that you have no colors. This default DIRCOLORS lists all the colorizable terms:
But the problem is that /etc/profile.d/term256.sh is executed after /etc/profile.d/colorls.sh. This is a problem because it is term256.sh which sets $TERM to xterm-256color. So when colorls.sh is executed the $TERM is still plain 'xterm'.
Line 33 of colorls.sh calls:
eval "`dircolors --sh "$COLORS" 2>/dev/null`"
This fails to export LS_COLORS as dircolors returns an empty LS_COLORS because the TERM environment variable which is plain 'xterm' doesn't have a match in the colorizable TERM list from the .dir_colors.
I don't know if /etc/profile.d scripts should have a dependency ordering between themselves, it is up to you to decide where this should be fixed.
OK so this doesn't look like a regression at least.
I get the same behavior with /etc/profile.d/term256.sh present or not.
I.E. if you: cp /etc/DIR_COLORS.256color ~/.dir_colors
and you haven't otherwise set TERM=xterm-256color
then colorls.sh will not setup the LS_COLORS env variable,
and thus you'll get the _default set_ of ls colors.
But yes to auto set LS_COLORS to the 256 color set
(including a 256 color set in ~/.dir_colors)
we'll need to rename term256.sh to run earlier.
Well actually you don't get the default set of LS_COLORS because the colorls.sh returns before setting the ll,ls,l. aliases, so you end up with ll, ls and l. without --color=auto:
eval "`dircolors --sh "$COLORS" 2>/dev/null`"
[ -z "$LS_COLORS" ] && return <-- Here the script returns
Yes fair point (I had a local ls alias masking that fact).
So we've got all the details now I think,
and it's not a regression from previous behavior,
but still needs to be fixed up.
So, a simple move of term256.sh to 256term.sh will suffice?
Yes. POSIX and bash guarantee the glob will sort before colorls.sh.
Created attachment 672156 [details]
ensure ls auto enables 256 colors
trivial patch attached in case it saves some typing
Fixed in git, likely won't make final unless there's a slip or another blocker.
initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2 has been submitted as an update for Fedora 18.
Package initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing initscripts-9.42.2-1.fc18 systemd-197-1.fc18.2'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
This breaks in Fedora 21 due to https://git.gnome.org/browse/gnome-terminal/commit/?id=1d5c1b6ca6373c1301494edbc9e43c3e6a9c9aaf
I suppose we could augment the script to check $VTE_VERSION
though I've asked the author of the commit above to comment first.
Created attachment 960055 [details]
used 256 colors by default with gnome-terminal
Reopening this as the feature is broken on the default terminal in Fedora 21.
The simple patch above should suffice, as the author of the gnome-terminal patch referenced above indicated that he wasn't considering reinstating the COLORTERM env variable.
See bug #1165439 for this regression.