Bug 31524 - ls's color for broken symlinks is missing in terms in Xfce or KDE started by dm
Summary: ls's color for broken symlinks is missing in terms in Xfce or KDE started by dm
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: coreutils (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-21 00:31 MSK by Ivan Zakharyaschev
Modified: 2015-11-24 21:18 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Zakharyaschev 2015-11-21 00:31:02 MSK
coreutils-8.24.0.40.c1dba-alt1 (from Sisyphus) and 8.16-alt1 (from t6)

I have had the impression that ls (at least, ls -l) would color broken symlinks in red.

But this is not so:

mkdir test-ls-orphan-symlink
cd test-ls-orphan-symlink
touch a
ln -s a b
ln -s z c

b and c appear the same (in cyan).

So, I had a look in an Ubuntu 12.04, and there the broken symlinks were shown in red.

Is it a bug (or a security feature)?

Can the red color for broken symlinks be turned on in ALT?
Comment 1 Ivan Zakharyaschev 2015-11-24 19:16:55 MSK
(It may be important whether the test is done with "ls -l" or "ls". Unfortunately, I haven't noticed this.)

I've tested this on my computer and on basalt (which have the same version of coreutils). ls on basalt uses the red color for broken symlinks, whereas the one on my computer doesn't:

"c" is red, "b" is cyan:

[imz@basalt test-ls-symlink]$ /bin/ls --color=always
a  b  c
[imz@basalt test-ls-symlink]$ ls -l
итого 0
-rw-r--r-- 1 imz imz 0 ноя 20 18:42 a
lrwxrwxrwx 1 imz imz 1 ноя 20 18:42 b -> a
lrwxrwxrwx 1 imz imz 1 ноя 20 18:42 c -> z
[imz@basalt test-ls-symlink]$ rpm -qf /bin/ls
coreutils-8.24.0.40.c1dba-alt1
[imz@basalt test-ls-symlink]$ 
[imz@basalt test-ls-symlink]$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
[imz@basalt test-ls-symlink]$ 

On my computer:

"c" and "a" are cyan both.

[imz@ovicaa test-ls-symlink]$ /bin/ls --color=always
a  b  c
[imz@ovicaa test-ls-symlink]$ /bin/ls --color=always -l
total 0
-rw-r--r-- 1 imz imz 0 ноя 20 18:42 a
lrwxrwxrwx 1 imz imz 1 ноя 20 18:42 b -> a
lrwxrwxrwx 1 imz imz 1 ноя 20 18:42 c -> z
[imz@ovicaa test-ls-symlink]$ rpm -qf /bin/ls
coreutils-8.24.0.40.c1dba-alt1
[imz@ovicaa test-ls-symlink]$ 
[imz@ovicaa tests]$ locale
LANG=ru_RU.utf8
LC_CTYPE="ru_RU.utf8"
LC_NUMERIC="ru_RU.utf8"
LC_TIME="ru_RU.utf8"
LC_COLLATE="ru_RU.utf8"
LC_MONETARY="ru_RU.utf8"
LC_MESSAGES=POSIX
LC_PAPER="ru_RU.utf8"
LC_NAME="ru_RU.utf8"
LC_ADDRESS="ru_RU.utf8"
LC_TELEPHONE="ru_RU.utf8"
LC_MEASUREMENT="ru_RU.utf8"
LC_IDENTIFICATION="ru_RU.utf8"
LC_ALL=
[imz@ovicaa test-ls-symlink]$ echo $TERM
xterm
[imz@ovicaa tests]$ 

That was in an xterm.

However, on my computer in linux console, red color is used.
Comment 2 Ivan Zakharyaschev 2015-11-24 19:29:21 MSK
This happens only in xterms in Xfce started by dm.

If I run startx from linux console, the red color is used.
Comment 3 Ivan Zakharyaschev 2015-11-24 19:41:52 MSK
The difference is that LS_COLORS is absent in sessions started by dm. (No matter whether it will be Xfce in SimplyLinux or KDE.)

This is because /etc/profile.d/color_ls.sh is not evaluated.

This is what is missing in the environment:

LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
Comment 4 Ivan Zakharyaschev 2015-11-24 19:46:45 MSK
However, ~/.bash_profile seems to be read and eval'd (because my custom PATH from there gets set).
Comment 5 Ivan Zakharyaschev 2015-11-24 20:03:22 MSK
A test script in /etc/profile.d/ has proven that it is eval'd.

So, the problem is that (possibly) dm unsets LS_COLORS.
Comment 6 Ivan Zakharyaschev 2015-11-24 20:07:48 MSK
Perhaps, /etc/profile.d/color_ls.sh is eval'd when TERM is unset (in dm). That's the reason that nothing is configured.

And the reason that it works after startx may be just a lucky coincidence: it has TERM=linux inherited from the linux console.
Comment 7 Ivan Zakharyaschev 2015-11-24 20:14:25 MSK
(In reply to comment #6)

> And the reason that it works after startx may be just a lucky coincidence: it
> has TERM=linux inherited from the linux console.

No, another reason: it inherits the LS_COLORS from the environment where startx is run. (I've checked startx with either unset TERM or LS_COLORS.)
Comment 8 Ivan Zakharyaschev 2015-11-24 20:29:38 MSK
Workaround suggested by ldv@: xterm -ls

What's bad in putting this script in bashrc? bashrc is eval'd in interactive shells only, and similar alias.sh and bash_completion.sh are in /etc/bashrc.d/ and probably no one seriously complains about them making bashrc too heavy-weight.
Comment 9 Ivan Zakharyaschev 2015-11-24 20:38:41 MSK
I hoped that /etc/bashrc is eval'd only in interactive shells (according to the manpage), but "unfortunately" we have BASH_ENV=/home/imz/.bashrc with the same effect for non-interactive shells...
Comment 10 Ivan Zakharyaschev 2015-11-24 20:43:19 MSK
But actually /etc/bahsrc can (and does) check whether the shell is interactive, and configuring the colors in /etc/bashrc.d/ would not be executed in non-interactive shells.
Comment 11 Ivan Zakharyaschev 2015-11-24 21:18:57 MSK
Just for information: Ubuntu 12.04 has it in /etc/skel/.bashrc:

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

-----

$ dpkg-query -S /etc/skel/.bashrc 
bash: /etc/skel/.bashrc
$