FS#16996 - [initscripts] 2009.08-1 colors messed up in terminal emulators

Attached to Project: Arch Linux
Opened by Steven E. Lamberson, Jr. (lamberss) - Tuesday, 03 November 2009, 22:56 GMT
Last edited by Thomas Bächler (brain0) - Wednesday, 09 June 2010, 17:44 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
When I restart a service in the console, everything looks fine (i.e. exactly like it did while booting). But when I restart a service in a terminal emulator in X (such as urxvt or xterm), the colors are messed up.

For example, using the default color palette for xterm (black text on white background), the text colors for the rc messages are bold white on a black background. This is annoying but readable. However, when I use my light on dark urxvt color palette (attached file "Xresources"), the result is black text on an almost black background. This text is unreadable, and I have to copy and paste it somewhere else to see what it said.

IMO, the rc scripts should use the default background and foreground colors of whatever terminal environment the script is called from. I have attached a patch (attached file "function.patch") that accomplishes this on my system (it fixes the color problem in the terminal emulators, but everything looks the same as it did from the console).


Additional info:
* package version: 2009.08-1


Steps to reproduce:
1. Make sure USECOLOR="yes" in /etc/rc.conf
2. Start X
3. Start xterm with default colors
4. Restart a service (i.e. sudo /etc/rc.d/sshd restart)
   functions.patch (1 KiB)
   Xresources (0.9 KiB)
This task depends upon

Closed by  Thomas Bächler (brain0)
Wednesday, 09 June 2010, 17:44 GMT
Reason for closing:  No response
Additional comments about closing:  Seems to be fine now, reopen if you don't think so.
Comment by Thomas Bächler (brain0) - Monday, 09 November 2009, 14:18 GMT
Can you please confirm that the behaviour is still the same on 2009.10-1? I don't think we changed anything there, but I wanna be sure.
Comment by Thomas Bächler (brain0) - Monday, 09 November 2009, 14:18 GMT
Sorry, 2009.11-1.
Comment by Steven E. Lamberson, Jr. (lamberss) - Tuesday, 10 November 2009, 21:24 GMT
Yes, the behavior is still in 2009.11-1. The patch I submitted still corrects the behavior on my system.
Comment by Thomas Bächler (brain0) - Tuesday, 10 November 2009, 21:27 GMT
Okay - I guess this patch looks fine, will apply it after checking it.
Comment by Dan McGee (toofishes) - Tuesday, 10 November 2009, 21:43 GMT
This might be helpful for troubleshooting.
   ansicolortable (0.4 KiB)
Comment by Dan McGee (toofishes) - Tuesday, 10 November 2009, 22:04 GMT
@Steven- can you explain what the "\033[1;29m" escape sequence is needed for in the two places it is used? Namely the 29 part; I don't see any documentation at all about that in ANSI color sequence land.
Comment by Gavin Bisesi (Daenyth) - Wednesday, 11 November 2009, 14:03 GMT
I think the current setup was from  FS#1186 
Comment by Steven E. Lamberson, Jr. (lamberss) - Wednesday, 11 November 2009, 14:24 GMT
I cannot find any documentation about the "\033[1;29m" sequence either.

What it appears to do is turn on bold for whatever the current color is. For example, the sequence
"\033[0;36m\033[1;29m" would appear as bolded cyan (the same as \033[1;36m).

I used this in these particular cases because I needed to use "\033[0m" to set the foreground to the correct color, but there is no option to automatically set this color to bold (i.e. there is no "\033[1;0m").
Comment by Simon Gomizelj (simongmzlj) - Saturday, 21 November 2009, 21:44 GMT
@Steven E. Lamberson, Jr. (lamberss)
\033[0m\033[1m works.
Comment by Aaron Griffin (phrakture) - Wednesday, 25 November 2009, 17:55 GMT
Please see  FS#1186 

The black background was added on purpose because it is completely unreadable _by default_ in white background terminals (i.e. gnome-terminal)

If someone can come up with a colorscheme for these messages that works out-of-the-box on both white and black backgrounds using the default colorscheme, I'd be more than happy to remove the black background.

That said, it's trivially easy to make your own custom colors for these things by copying the color section and placing it in a file in /etc/rc.d/functions.d/
Comment by Simon Gomizelj (simongmzlj) - Wednesday, 25 November 2009, 18:03 GMT
This patch does the trick
Comment by Aaron Griffin (phrakture) - Wednesday, 25 November 2009, 18:18 GMT
Yes, but, as I stated, this patch brings us back to the original issue with white terminals, so I am not interested in solving it. The current choices are: unreadable text on white backgrounds, or an unattractive black block. I'll go with the unattractive and READABLE choice here.

The only proper solution would be to mess with the colors such that rc.d scripts output fine on a white terminal that uses the default color scheme
Comment by Simon Gomizelj (simongmzlj) - Wednesday, 25 November 2009, 18:24 GMT
Okay, I though I checked that out with this patch; I thought it was addressed. I know my patch, attached to the duplicate post, addresses that. These patches respect the set foreground text, it doesn't draw white text (see screenshot in duplicate bug report). I achieved this in my patch by resetting the colour and then just setting the bold flag. This patch does it differently. The result, black text on a white background, or white text on a black background (assuming the foreground colour was set sanely)
Comment by Steven E. Lamberson, Jr. (lamberss) - Tuesday, 01 December 2009, 17:12 GMT
With the patch I attached to the original bug report, the rc.d function output is READABLE in the gnome-terminal with default black on white setting.
Comment by Thomas Dziedzic (tomd123) - Thursday, 27 May 2010, 04:19 GMT
status?

Loading...