In sys-apps/coreutils-8.25, TERM entries in /etc/DIR_COLORS have been changed to use glob patterns. Thus, the simplistic check of "safe_term" against the contents of DIR_COLORS used in /etc/bash/bashrc fails e.g. for gnome-terminal (TERM being "xterm-256color", safe_term being "xterm?256color"). This results in the prompt having no color, and the color settings for other commands not being set. Reproducible: Always
Created attachment 423578 [details, diff] Patch to fix color detection I now attached a patch for /etc/bash/bashrc. The main idea is to let dircolors itself figure out whether the terminal has color. Re-implementing parsing of the dircolors database in bashrc is bound to introduce breakage like this. It's also more efficient since it avoids duplicating the parsing, as dircolors is called anyway to setup the colors.
Created attachment 423580 [details, diff] Patch to fix color detection Oops, small fixes of variable handling...
I have also found this problem after updating to coreutils-8.25, and have verified that the patch resolves the problem. Based on the history of the gentoo bashrc file (https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-shells/bash/files/bashrc?view=log), the colour code has gone through a long evolution of changes. Is there a correct behaviour that should be applied here, and does this patch now give us that behaviour? Regarding the patch, wouldn't the the $LS_COLORS test be best written as [[ -n "$LS_COLORS" ]] (test for non-zero length string).
Created attachment 423724 [details, diff] Patch to fix color detection (In reply to keeperofdakeys from comment #3) > Regarding the patch, wouldn't the the $LS_COLORS test be best written as [[ > -n "$LS_COLORS" ]] (test for non-zero length string). Yes, that's right... Better than the old kludge. Now included as suggested.
Created attachment 423726 [details, diff] Patch to fix color detection Oops, now with the correct diff...
the only reason for using bash like this was to avoid execing programs entirely. the pattern match was straight forward with loading the file content. however, the way the code is written, we always run dircolors when the TERM is color enabled. which means it's just saving interactive shells that load profile/bashrc code under a TERM that lacks color support from running dircolors. for non-interactive shells, this file wouldn't generally load in the first place. so practically speaking, that's a minority, so always running dircolors is probably fine.
this is kind of murky explanation. downgrading to 8.24 meanwhile. not a good experience getting TERMS breakage by such updates without testing first.
I guess this is a good opportunity to ask this: why do we not properly quote the argumenta in "eval $(dircolors -b ~/.dir_colors)" and "eval $(dircolors -b /etc/DIR_COLORS)"? It makes it subject to uncalled word splitting and further pathname expansions, no? I had an issue once because of it, and quoting fixed it: eval "$(dircolors -b ~/.dir_colors)", eval "$(dircolors -b /etc/DIR_COLORS)". Might as well to take the opportunity to include it in the patch.
(In reply to Oleg from comment #7) really no idea what you're trying to say. if you don't have anything useful to contribute, then just refrain from posting. (In reply to konsolebox from comment #8) because no one filed a bug pointing it out before.
*** Bug 573196 has been marked as a duplicate of this bug. ***
Created attachment 424454 [details, diff] Patch to fix color detection Updated patch: - For completeness, if neither ~/.dir_colors nor /etc/DIR_COLORS are available, use the data base compiled into dircolors - Quote the argument of eval as suggested by konsolebox, https://bugs.gentoo.org/show_bug.cgi?id=572582#c8
Created attachment 424486 [details, diff] Patch to fix color detection (against bashrc in portage tree) (In reply to Bernd Feige from comment #11) > Created attachment 424454 [details, diff] [details, diff] > Patch to fix color detection > > Updated patch: > - For completeness, if neither ~/.dir_colors nor /etc/DIR_COLORS are > available, use the data base compiled into dircolors > - Quote the argument of eval as suggested by konsolebox, > https://bugs.gentoo.org/show_bug.cgi?id=572582#c8 I just applied this patch to the bashrc in portage (/usr/portage/app-shells/bash/files/bashrc), the second chunk failed to apply, but after some manual cleanup I would say that the problem is solved in my environment. Is this to be applied against a version of bashrc other than the one in portage right now? I did not override the other patch because I am not sure of that. md5sum /usr/portage/app-shells/bash/files/bashrc 62b2fbca4ba4576fe4c4a1c13f5233d5 /usr/portage/app-shells/bash/files/bashrc I attached a corrected patch that applies to the bashrc currently in portage if it helps.
(In reply to Tiago Batista from comment #12) > Created attachment 424486 [details, diff] [details, diff] > Patch to fix color detection (against bashrc in portage tree) > > (In reply to Bernd Feige from comment #11) > > Created attachment 424454 [details, diff] [details, diff] [details, diff] > > Patch to fix color detection > > > > Updated patch: > > - For completeness, if neither ~/.dir_colors nor /etc/DIR_COLORS are > > available, use the data base compiled into dircolors > > - Quote the argument of eval as suggested by konsolebox, > > https://bugs.gentoo.org/show_bug.cgi?id=572582#c8 > > I just applied this patch to the bashrc in portage > (/usr/portage/app-shells/bash/files/bashrc), the second chunk failed to > apply, but after some manual cleanup I would say that the problem is solved > in my environment. > > Is this to be applied against a version of bashrc other than the one in > portage right now? I did not override the other patch because I am not sure > of that. > > md5sum /usr/portage/app-shells/bash/files/bashrc > 62b2fbca4ba4576fe4c4a1c13f5233d5 /usr/portage/app-shells/bash/files/bashrc > > I attached a corrected patch that applies to the bashrc currently in portage > if it helps. Ok, with this patch no chunk failed. But the problem was fixed for me with the previous patch too. No difference for me.
Created attachment 424490 [details, diff] Patch to fix color detection Okay, thanks, updated patch should now be compatible for all, and the third dircolors uses the -b flag as should be...
Created attachment 424510 [details] bashrc rewritish give this one a try. it's actually a stack of fixes i have pending locally.
(In reply to SpanKY from comment #15) > Created attachment 424510 [details] > bashrc rewritish > > give this one a try. it's actually a stack of fixes i have pending locally. Works for me, thanks!
ok, i've pushed that now. i think i incorporated everyone's suggestions. quote dircolors output: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=485b78806bf288e68eae9988e2e9342df8d74959 always run dircolors: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=747857408315deb4b6a0ddd2a34484ca8e5ec2ff and there's a few other commits in there if people are interested
@SpanKY: Shouldn't you also unset the temporary ls_colors variable so it doesn't leak into the shell's variable namespace? (You unset used_default_dircolors but not ls_colors.)
(In reply to Matt Whitlock from comment #18) thanks, fixed here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=becfc11732db43397071f873487813165c0bdd85
