what is eating dircolors?

[Michal Jaegermann]

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