I failed to notice when precisely this happened but most likely as a side effect of recent updates (and this is not include 'dircolors', i.e. coreutils package which was installed on the box in question on Sat 17 Jul 2004). The gist of the problem is that if you are in X and in terminal window you type 'dircolors --sh', or 'dircolors --sh /etc/DIR_COLORS', or similar then an output is
LS_COLORS=''; export LS_COLORS
but if you do that on a console then you will get what you expect. I tried 'gnome-terminal' and 'xterm' so this does not seem to be an "improvement" in 'gnome-terminal'.
This is actually quite painful because if you do now 'ssh some.other.machine' then you will get the same deal. In /etc/profile.d/colorls.sh you will find a code which says:
eval `dircolors --sh "$COLORS"` [ -z "$LS_COLORS" ] && return
so these aliases:
alias ll='ls -l --color=tty' 2>/dev/null alias l.='ls -d .* --color=tty' 2>/dev/null alias ls='ls --color=tty' 2>/dev/null
are never defined so depending on if you logged from an "older" Linux machine and/or from a console or a terminal window you are getting an enviroment which looks and behaves differently. I would hate trying to explain that to my users.
I would file a bug but I am not really sure what is really responsible for that "great feature". So far I failed to notice where this may be even documented but something tells me that TERM=gnome may be responsible. If this is really the case then
alias dircolors='TERM=xterm \dircolors'
all over the place would work around that but this still does nothing to older Linux hosts where you may want to login unless you do that there as well. '[ "$TERM" = gnome ] && export TERM=xterm' seems like a more radical solution. Hm, maybe in an alias for ssh, with a TERM replacement like above, instead. OTOH 'dircolors' documentation does not mention anything that its output may be TERM dependent. Another bug?
Michal
On Sat, Jul 31, 2004 at 04:05:36PM -0600, Michal Jaegermann wrote:
So far I failed to notice where this may be even documented but something tells me that TERM=gnome may be responsible.
Commenting on my own posting: looking at sources instead of documentation indeed the above is the case. LS_COLORS will be non-empty only if in a file with color definitions, say /etc/DIR_COLORS, there is an entry for a termtype you happen to be using. So addding there on a target host a line
TERM gnome
makes 'dircolors' to behave like expected.
The catch, of course, is that you may have many Linux systems around where you are connecting and not necessarily an access to DIR_COLORS files there. You may use a file in your home directory on a target but, again, I do not see where this is documented in a explicit manner.
In general for non-Linux systems I suspect that hardly anything will know what TERM=gnome will happen to be and this will affect many programs. Think 'vi', 'less' and 'man' for a start. Was a decision to switch to this termtype deliberate? Even if you open an xterm window it says 'gnome' for 'echo $TERM'. Sounds like a recipe for a big mess.
Michal
--- Michal Jaegermann michal@harddata.com wrote:
On Sat, Jul 31, 2004 at 04:05:36PM -0600, Michal Jaegermann wrote:
So far I failed to notice where this may be even documented but something
tells me that
TERM=gnome may be responsible.
In general for non-Linux systems I suspect that hardly anything will know what TERM=gnome will happen to be and this will affect many programs.
I'm already being affected; I can't login to an IRIX system as I'm used to do before from a FC3t1 system. It now complain "unknown terminal TERM=gnome", won't set my environment variable properly and thus I can do anything on it. Anyone care to let me know how to revert to the old terminal type on my FC3t1. Thanks.
Was a decision to switch to this termtype deliberate? Even if you open an xterm window it says 'gnome' for 'echo $TERM'. Sounds like a recipe for a big mess.
Michal
Deji
______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca
On Sun, Aug 01, 2004 at 06:40:04PM -0400, Deji Akingunola wrote:
--- Michal Jaegermann michal@harddata.com wrote:
In general for non-Linux systems I suspect that hardly anything will know what TERM=gnome will happen to be and this will affect many programs.
I'm already being affected; I can't login to an IRIX system as I'm used to do before from a FC3t1 system. It now complain "unknown terminal TERM=gnome", won't set my environment variable properly and thus I can do anything on it.
Well, you can type 'TERM=xterm' (or equivalent depending on which shell you happen to be using on IRIX) and this should make your IRIX much happier.
You can also set 'TERM=xterm' before starting a connection to IRIX. 'gnome' terminal type is 'xterm' plus some few extras so you are not loosing that much.
Or, if you are using bash and ssh for that login then you can drop as - say - /etc/profile.d/ssh.sh, or elsewhere in your startup files, something of that sort
# executing ssh in a subshell to get environment automatically back
if [ -x "$(type -fp ssh)" ] ; then ssh () { ( [ "$TERM" = gnome ] && TERM=xterm $(type -fp ssh) $@ ) } fi
and similar for other things where you would need such change. That will solve vanishing colours in 'ls' even if you are doing 'ssh localhost' on FC3t1. :-) The above depends on 'type' from bash-3 and you would have either "hardwire" a location of ssh or play more complicated games with earlier bash versions.
For those using csh I will leave to them to hack an equivalent of such shell function. :-)
Last, but not least, you can modify your TERM globally back to 'xterm', which is trivial, but we are supposed to be testing.
Michal
-
Deji Akingunola -
Michal Jaegermann