Re: How to make the colors different for a symbol link pointing to a file and symbol link pointing to a dir?

[Chris Jones]

On Thu, Dec 31, 2009 at 09:18:42PM EST, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Chris Jones on 12/31/2009 8:31 AM:
> > $ ls -alh -F --full-time --color=always
> > 
> > drwxr-xr-x  7 user user 4.0K 2009-12-31  [..]  -0500 ./
> > drwxrwxrwt 27 root root  12K 2009-12-31  [..]  -0500 ../
> > drwxr-xr-x  2 user user 4.0K 2009-12-31  [..]  -0500 d1/
> > -rw-r--r--  1 user user    0 2009-12-31  [..]  -0500 f1
> > lrwxrwxrwx  1 user user    3 2009-12-31  [..]  -0500 argetmld1: -> d1:
> 
> > coreutils     6.10-6                       The GNU core utilities
> 
> Wow, that's old.  

That is the privilege of running debian "stable".

> The latest stable version is 8.2.  I'm not reproducing your behavior,
> whether I tested with 7.0 or the latest git.  It looks like ls is
> misinterpreting the 'ln=target' portion of LS_COLORS, and trying to
> treat the last 5 characters as literal bytes to output for the color
> sequence rather than treating the whole directive as a command to swap
> the coloring rules over to following through the symlink.  I didn't
> see anything in the NEWS that specifically mentions a change in that
> area, but I may have overlooked something.

I ran another test and this time was unable to recreate.

So, I went through my bash session's history file and extracted the
commands I had issued to the following script:

------------------------------------------------------------------------
#!/bin/bash
cd /tmp/dirtests
mkdir dir1
cd dir1
mkdir d1 d2 d3 
for i in $(ls d*); do  ln -s $i l$i; echo l$i; done
ls -alh -F --full-time --color=always
------------------------------------------------------------------------

:-(

The 'ls d*' explains the appended colons and has nothing to do with
dircolors.

The only curious behavior is the following:

1. Untainted shell:

------------------------------------------------------------------------
$ ls -alh -F --full-time --color=always
drwxr-xr-x 5  [..]  2010-01-01 07:12:50.000000000 -0500 .
drwxr-xr-x 4  [..]  2010-01-01 07:19:40.000000000 -0500 ..
drwxr-xr-x 2  [..]  2010-01-01 07:01:56.000000000 -0500 d0
drwxr-xr-x 2  [..]  2010-01-01 07:01:56.000000000 -0500 d1
drwxr-xr-x 2  [..]  2010-01-01 07:01:56.000000000 -0500 d3
lrwxrwxrwx 1  [..]  2010-01-01 07:12:27.000000000 -0500 ld0: -> d0:
lrwxrwxrwx 1  [..]  2010-01-01 07:12:27.000000000 -0500 ld1: -> d1:
lrwxrwxrwx 1  [..]  2010-01-01 07:12:27.000000000 -0500 ld3: -> d3:
------------------------------------------------------------------------

2. Tainted¹ shell:

------------------------------------------------------------------------
$ ls -alh -F --full-time --color=always
drwxr-xr-x 5  [..]  2010-01-01 07:12:50.000000000 -0500 ./
drwxr-xr-x 4  [..]  2010-01-01 07:19:40.000000000 -0500 ../
drwxr-xr-x 2  [..]  2010-01-01 07:01:56.000000000 -0500 d0/
drwxr-xr-x 2  [..]  2010-01-01 07:01:56.000000000 -0500 d1/
drwxr-xr-x 2  [..]  2010-01-01 07:01:56.000000000 -0500 d3/
lrwxrwxrwx 1  [..]  2010-01-01 07:12:27.000000000 -0500 argetmld0: -> d0:
lrwxrwxrwx 1  [..]  2010-01-01 07:12:27.000000000 -0500 argetmld1: -> d1:
lrwxrwxrwx 1  [..]  2010-01-01 07:12:27.000000000 -0500 argetmld3: -> d3:
------------------------------------------------------------------------

3. What bash sees:

------------------------------------------------------------------------
$ echo *
d0 d1 d3 ld0: ld1: ld3:
------------------------------------------------------------------------

¹By 'tainted', I mean a shell where the dircolors command picked up the
'LINKED target' statement in my ~/.dircolors database.

As a matter of fact, once I get rid of the 'ls d*' nonsense, the 'ls -F'
and "LINKED target' combinations works as advertised, with both the link
and the target colored in pale blue for a directory 'ld0 -> d0' and the
corresponding 'lf0 -> f0' for regular files in the default white.

So recreating the problem was really as simple as ln'ing a broken soft
link:

------------------------------------------------------------------------
$ ln -s xxx lxxx            # where there is no such file as 'xxx'
------------------------------------------------------------------------

There must be some good reason why 'ln' accepts to create such links in
the first place. Doesn't bother me, since I could remove the target
after the fact, just makes it easier to create broken links, I guess. 

OTOH, maybe the spurious display of 'argetm' - not sure where the 'm'
comes from - could be considered a bug. Or maybe a feature, since is
does make broken links very visible? 

I'll boot into debian testing and ubuntu 9.10 later today, and see what
versions of coreutils they ship.. see if I can still reproduce.

Would have the added merit that AFAIRC, I haven't fiddled the dircolors
stuff on those systems.

> But rest assured that your filesystem was not altered - the spurious
> 'arget' in the listing comes from a bad attempt at outputting a color
> code, not from a changed name.
> 
> - --
> Don't work too hard, make some time for fun as well!

Thanks for the tutoring, and Happy 2010.

CJ