Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 849429 - Fedora 18 256 color terminal feature
Fedora 18 256 color terminal feature
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2012-08-19 08:16 EDT by Pádraig Brady
Modified: 2016-01-04 09:47 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-12-09 14:17:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
script to enable feature (2.94 KB, patch)
2012-08-19 08:16 EDT, Pádraig Brady
no flags Details | Diff
ensure ls auto enables 256 colors (1.46 KB, patch)
2013-01-03 14:08 EST, Pádraig Brady
no flags Details | Diff
used 256 colors by default with gnome-terminal (1.42 KB, application/mbox)
2014-11-21 23:14 EST, Pádraig Brady
no flags Details

  None (edit)
Description Pádraig Brady 2012-08-19 08:16:13 EDT
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:
Comment 1 Kevin Raymond 2012-09-03 15:18:09 EDT
Is there any plan to take this patch into account before the F18 Beta release?
Comment 2 Bill Nottingham 2012-09-10 13:53:21 EDT
Apologies - have been traveling and tied up in other things. This will happen before beta, but not before alpha.
Comment 3 Bill Nottingham 2012-09-14 16:13:12 EDT
Added in git, with tweaks to the comments suggesting methods of setting SEND256... that don't involve editing the packaged profile.d files.
Comment 4 Pádraig Brady 2012-09-14 16:32:47 EDT
I checked your amendments at http://git.fedorahosted.org/cgit/initscripts.git/commit/?id=c819f19 which make lots of sense.

Comment 6 Ozan Çağlayan 2012-12-19 13:48:21 EST
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.
Comment 7 Bill Nottingham 2012-12-19 14:26:56 EST
This is because the local file doesn't have a current list of colorizable terms, correct?
Comment 8 Pádraig Brady 2012-12-19 16:47:39 EST
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?
Comment 9 Ondrej Vasik 2012-12-20 04:05:09 EST
Ozan: Could you please be more specific what's broken on colorls.sh in F18?
Comment 10 Ozan Çağlayan 2012-12-20 04:23:32 EST
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:

TERM putty-256color
TERM rxvt-256color
TERM rxvt-unicode-256color
TERM rxvt-unicode256
TERM screen-256color
TERM xterm-256color
TERM gnome-256color

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.
Comment 11 Pádraig Brady 2012-12-20 05:17:14 EST
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.

Comment 12 Ozan Çağlayan 2012-12-20 06:49:10 EST
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
Comment 13 Pádraig Brady 2012-12-20 07:31:47 EST
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.

Comment 14 Bill Nottingham 2012-12-20 10:21:54 EST
So, a simple move of term256.sh to 256term.sh will suffice?
Comment 15 Pádraig Brady 2012-12-20 12:28:05 EST
Yes. POSIX and bash guarantee the glob will sort before colorls.sh.
Comment 16 Pádraig Brady 2013-01-03 14:08:24 EST
Created attachment 672156 [details]
ensure ls auto enables 256 colors

trivial patch attached in case it saves some typing
Comment 17 Bill Nottingham 2013-01-03 14:21:10 EST
Fixed in git, likely won't make final unless there's a slip or another blocker.
Comment 18 Fedora Update System 2013-02-21 04:08:15 EST
initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2 has been submitted as an update for Fedora 18.
Comment 19 Fedora Update System 2013-02-22 20:03:33 EST
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).
Comment 20 Fedora Update System 2013-02-25 21:45:24 EST
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.
Comment 21 Pádraig Brady 2014-11-20 22:29:46 EST
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.
Comment 22 Pádraig Brady 2014-11-21 23:14:45 EST
Created attachment 960055 [details]
used 256 colors by default with gnome-terminal
Comment 23 Pádraig Brady 2014-11-21 23:18:30 EST
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.
Comment 24 Josh Stone 2014-12-09 13:52:34 EST
See bug #1165439 for this regression.

Note You need to log in before you can comment on or make changes to this bug.