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 Fri, Jan 01, 2010 at 08:48:04AM EST, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Chris Jones on 1/1/2010 6:20 AM:

> > 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'
> > ----------------------------------------------------------------------
> > 

> Ahh. You have indeed discovered a real bug¹, still broken in the
> latest git sources.

Phew..! some effort, was it not.. :-)

> $ rm -Rf a b
> $ ln -s a b
> $ LS_COLORS=ln=target src/ls -ld --color=auto b
> lrwxrwxrwx 1 eblake None 1 2010-01-01 06:41 argetmb -> a

> > There must be some good reason why 'ln' accepts to create such links
> > in the first place.

> And that reason is that POSIX requires it.

Glad to know that there is more to it than a hunch that this was the
expected behavior.

> > OTOH, maybe the spurious display of 'argetm' - not sure where the
> > 'm' comes from - could be considered a bug. Or maybe a feature,
> > since it does make broken links very visible? 
> 
> The m is leftovers from the fact that \033[t is a valid terminal
> sequence, when normally you would use \033[34m as the terminal
> sequence to select blue.  Observe:

> $ LS_COLORS=ln=34 src/ls -ld --color=always b | od -tx1z -w12
> 0000000 6c 72 77 78 72 77 78 72 77 78 20 31  >lrwxrwxrwx 1<
> 0000014 20 65 62 6c 61 6b 65 20 4e 6f 6e 65  > eblake None<
> 0000030 20 31 20 32 30 31 30 2d 30 31 2d 30  > 1 2010-01-0<
> 0000044 31 20 30 36 3a 34 31 20 1b 5b 30 6d  >1 06:41 .[0m<
> 0000060 1b 5b 33 34 6d 62 1b 5b 30 6d 20 2d  >.[34mb.[0m -<
> 0000074 3e 20 61 0a 1b 5b 6d                 >> a..[m<
> 0000103
> $ LS_COLORS=ln=target src/ls -ld --color=always b | od -tx1z -w12
> 0000000 6c 72 77 78 72 77 78 72 77 78 20 31  >lrwxrwxrwx 1<
> 0000014 20 65 62 6c 61 6b 65 20 4e 6f 6e 65  > eblake None<
> 0000030 20 31 20 32 30 31 30 2d 30 31 2d 30  > 1 2010-01-0<
> 0000044 31 20 30 36 3a 34 31 20 1b 5b 30 6d  >1 06:41 .[0m<
> 0000060 1b 5b 74 61 72 67 65 74 6d 62 1b 5b  >.[targetmb.[<
> 0000074 30 6d 20 2d 3e 20 61 0a 1b 5b 6d     >0m -> a..[m<
> 0000107

Great tip and explanation. Part of what caused my initial problem
tracking this down was not being able to access the raw data.

> It is not a feature; 

I guess I should have added another smiley.

> we'll have it fixed for coreutils 8.3.

I didn't have the time to check the squeeze/karmic systems. 

Thank you,

CJ

¹ Maybe I'm pushing it, but while I'm at it, maybe another minor
  'bug/feature' is the fact that the way some dircolors options are
  documented is questionable, or at least unexpected - dircolors -p
  making it all too easy to miss the description of 'LINK target'.