Bug 849429 - Fedora 18 256 color terminal feature
Summary: Fedora 18 256 color terminal feature
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 21
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-08-19 12:16 UTC by Pádraig Brady
Modified: 2016-01-04 14:47 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-12-09 19:17:10 UTC
Type: Bug

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

Description Pádraig Brady 2012-08-19 12:16:13 UTC
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 19:18:09 UTC
Is there any plan to take this patch into account before the F18 Beta release?

Comment 2 Bill Nottingham 2012-09-10 17:53:21 UTC
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 20:13:12 UTC
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 20:32:47 UTC
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 18:48:21 UTC
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 19:26:56 UTC
This is because the local file doesn't have a current list of colorizable terms, correct?

Comment 8 Pádraig Brady 2012-12-19 21:47:39 UTC
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 09:05:09 UTC
Ozan: Could you please be more specific what's broken on colorls.sh in F18?

Comment 10 Ozan Çağlayan 2012-12-20 09:23:32 UTC
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 10:17:14 UTC
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 11:49:10 UTC
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 12:31:47 UTC
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 15:21:54 UTC
So, a simple move of term256.sh to 256term.sh will suffice?

Comment 15 Pádraig Brady 2012-12-20 17:28:05 UTC
Yes. POSIX and bash guarantee the glob will sort before colorls.sh.

Comment 16 Pádraig Brady 2013-01-03 19:08:24 UTC
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 19:21:10 UTC
Fixed in git, likely won't make final unless there's a slip or another blocker.

Comment 18 Fedora Update System 2013-02-21 09:08:15 UTC
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-23 01:03:33 UTC
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-26 02:45:24 UTC
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-21 03:29:46 UTC
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-22 04:14:45 UTC
Created attachment 960055 [details]
used 256 colors by default with gnome-terminal

Comment 23 Pádraig Brady 2014-11-22 04:18:30 UTC
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 18:52:34 UTC
See bug #1165439 for this regression.

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