| Summary: | dircolors produces harmful code 'rs=0' in prefix portage | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Rabbe Fogelholm <rabbe> |
| Component: | Prefix Support | Assignee: | Gentoo non-Linux Team <alt> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | shlomif |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Differences in `emerge --info' output between 2008-04-03 and 2008-08-14
strace from launch of mrxvt when LS_COLORS contains rs=0 |
||
|
Description
Rabbe Fogelholm
2008-08-14 08:19:51 UTC
Created attachment 162865 [details]
Differences in `emerge --info' output between 2008-04-03 and 2008-08-14
Differences in `emerge --info' output between 2008-04-03 and 2008-08-14.
http://forums.gentoo.org/viewtopic-t-699584.html?sid=9e0e88062520aede30c912769b60076c this forum thread suggests rs=0 is not prefix specific, and that RESET (would that be rs?) is introduced in a newer coreutils. It may have been introduced for you, as side effect of a fix in dircolors calling code that previously was not called due to a bug. Some more thoughts, written in parallel with your entry Fabian, There is an array ls_codes[] in dircolors.c, defined at line 69. A number of initial values are given. In the coreutils-6.12-r1 version there is a value "rs" at line 71; in the 6.10-r1 version this value is not present. The array slack_codes[], defined at line 60, appears to be related to ls_codes[]. In the 6.12-r1 version the initial value "RESET" has been introduced in the position that matches "rs". The ChangeLog of coreutils does not mention dircolors. Looking upstream, at <http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=history;f=src/dircolors.c;h=79109b93455762f988c79eca44ea31ada455dd8a;hb=HEAD>, it seems that "rs" appeared 2008-02-17 (Jim Meyering, "Adjust dircolors to match ls.c"). So, obviously "rs" was introduced for some good reason, yet it causes problems in prefix portage. Would it be a solution to simply revert to an older version of coreutils? I notice that a native Gentoo box of mine (not running ~x86 but otherwise up-to-date) has coreutils-6.10-r2. Well, for me it works fine, so I guess something of the host system is involved here that doesn't grok it. Another workaround would be to override LS_COLORS by setting an entry in your homedir which doesn't have the rs=0. I think a strace of xterm or mrxvt would be useful to identify what they're opening. Created attachment 162877 [details]
strace from launch of mrxvt when LS_COLORS contains rs=0
Here it is, 2284 lines, without having looked closely at it yet.
(In reply to comment #0) > The command `dircolors -b' produces a harmful code 'rs=0', among with many > legal codes, in prefix portage. Do you have references that say how it is harmful besides the error for you with xterm/mrxvt? It is hard to "point fingers" at the error when both grobian and I cannot reproduce this. Also, xterm not starting is kinda a big deal and no one else has brought this up. I agree with grobian, maybe the best solution here is for you to make your own .dir_colors file in $HOME since even you stated that this may not be reproducible on any other host. =/ With that being said, it is rather disturbing that this happened 'all of a sudden' and left you without a usable terminal one day. *shrugs* Some new insight today,
I have been using a bash wrapper of my own since the "startprefix" script is not entirely practical in my tcsh-heavy host environment. My bash wrapper did not reset SHELL in the environment so its value was /bin/tcsh, which is a 6.14.00 tcsh that doesn't understand "rs=0".
A better way to start a prefix shell for me (with the intention of running bash, to have less interactions with the host environment) is something like this:
tcsh> setenv EPREFIX /local/tmp/nightly/2008-08-15
tcsh> cd $EPREFIX
tcsh> set path = ($EPREFIX/usr/local/bin $EPREFIX/usr/bin \
$EPREFIX/bin $EPREFIX/usr/sbin $EPREFIX/sbin $path)
tcsh> setenv MANPATH $EPREFIX/usr/share/man:$MANPATH
tcsh> unsetenv PKG_CONFIG_PATH
tcsh> setenv SHELL /bin/bash
tcsh> exec ./startprefix
The LS_COLORS now includes the rs=0 code.
Having done so, xterm starts with no problem! And so does mrxvt. The previously seen message "Unknown colorls variable `rs'" in mrxvt was most likely produced by tcsh.
Not all terminal applications are happy though. For x11-terms/terminal-0.2.8 the command `terminal' refuses to start the application until I clear the rs=0 code from LS_COLORS.
how about: env SHELL=tcsh ./startprefix ? I'm a tcsh user, sometimes having to use bash as well, and that's how I do it. Anyone who knows what he/she is doing is welcome not to use startprefix, but my rule of thumb in environment problems like these is that if you don't use startprefix, I won't fix it, unless the same happens when using the startprefix script. Reason for this is that your "workaround" doesn't nearly do as much as startprefix. And it needs all those environment settings. Having SHELL point to /bin/tcsh is also poisonous, since anything that spawns a new shell (vim, mutt, screen, etc. etc.) will spawn the wrong shell, with misc environment problems as result. I think your problem is just one of them, which also explains why we couldn't reproduce. Just emerge your shell of choice and use ./startprefix. Solve problems afterwards (your pkgconfig for example, which indeed is a legitimate problem). Should we fix that in ./startprefix script? > Should we fix that in ./startprefix script?
Clearing PKG_CONFIG_PATH seems like a good idea.
What are your thoughts about PATH and MANPATH? Since startprefix knows where the prefix tree is it could ensure that the prefix path components are included.
It does, but I suspect your .tcshrc or .bashrc to override them. Precisely, this is what happens for tcsh over here. I wish I would have figured out the `env SHELL=bash startprefix' invocation, it would have saved me some trouble. And you and Jeremy--thanks indeed for your patience. I did a quick check on all terminals in x11-terms. They all emerge nicely. Usability is quite good too: pssh: not really a terminal? tilda: hangs when launching, unrelated to rs=0 terminal: refuses to start if rs=0 present, as reported before aterm, clusterssh, kterm, mrxvt, uxterm, xterm, gnome-terminal all work (for gnome-terminal one may have to emerge corefonts too, #235553). So there are a bunch of usable terminals to choose from. It is fine with me to close this bug with no action. (Someone might consider to report a problem for the combination of coreutils-6.12-r1 and x11-terms/terminal-0.2.8 of course?) This is an incompatibility between the latest coreutils and tcsh. It was also reported here: https://qa.mandriva.com/show_bug.cgi?id=40532 There's an ad-hoc patch to tcsh there as part of the grander mdvsys patch. Regards, -- Shlomi Fish This is not about tcsh. Gentoo already has the mentioned patch for tcsh for quite some time now. Anyway, thanks for the suggestion. I'll close this bug now as per the suggestion of the previous poster. |
