Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Fedora 18 256 color terminal feature|
|Product:||[Fedora] Fedora||Reporter:||Pádraig Brady <pbrady>|
|Component:||initscripts||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||21||CC:||alick9188, iarlyy, jistone, jonathan, kraymond, lnykryn, mattdm, maurizio.antillon, notting, ovasik, ozan.caglayan, p, plautrba, renault, rvokal, samuel-rhbugs, vpavlin|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-12-09 14:17:10 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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: https://fedoraproject.org/wiki/Features/256_Color_Terminals
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? Thanks,
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. thanks!
Comment 5 Pádraig Brady 2012-10-08 12:47:47 EDT
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. thanks.
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. thanks.
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. https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-1.fc18,systemd-197-1.fc18.2
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: https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-1.fc18,systemd-197-1.fc18.2 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.