ls -l --color: symlink target is no longer colored

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> Eric Blake <ebb9 <at> byu.net> writes:
>> | None of my symlink targets have a color anymore:
>> |
>> | Reverting to coreutils 6.9-5 shows the link targets in color again,
>> | and an strace on `ls -l y' shows the stat call for x.exe.
>>
>> Thanks for the report; this is probably an upstream bug.  But I will try
>> to investigate further.
>
> It looks like this commit is the culprit:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=0a74437
>
> It looks like a true regression.  The change was introduced because of this
> thread:
> http://lists.gnu.org/archive/html/bug-coreutils/2007-06/msg00004.html
> http://lists.gnu.org/archive/html/bug-coreutils/2007-07/msg00079.html
>
> It looks like when -l is NOT in effect, you should not stat the result of a
> symlink.  But when -l IS in effect, and C_EXEC is enabled, then the result of
> stat'ing the symling IS used, in order to color the symlink target differently
> than the color of the symlink.

Hi Eric,

Thanks for investigating that.
However, it's not really a regression.
The stated goal of that change was to avoid stat'ing through symlinks.
If you really want to stat through them anyhow (which might
cause a hang (stale mount) or spin up a an idle disk),
you can use the special "ln=target" directive.

However, maybe we need a new option:

With the latest coreutils, I get this without "-l":

  $ LS_COLORS='ex=1;31:ln=5;32' ls --color slink x.exe
  slink  x.exe        (green, red)

and same with coreutils-6.9.  So far so good.
But as you say, the difference is with -l.

[prepare: touch x.exe; chmod a+x x.exe; ln -s x.exe slink]
With coreutils-6.9:

  $ LS_COLORS='ex=1;31:ln=5;32' /cu/6.9/bin/ls -log --color slink x.exe
  lrwxrwxrwx 1 5 Apr 14 17:19 slink -> x.exe     (green, red)
  -rwxr-xr-x 1 0 Apr 14 17:19 x.exe              (red)

With latest:

  $ LS_COLORS='ex=1;31:ln=5;32' ls -log --color slink x.exe
  lrwxrwxrwx 1 5 Apr 14 17:19 slink -> x.exe     (green, *none*)
  -rwxr-xr-x 1 0 Apr 14 17:19 x.exe              (red)

Using the latest with ln=target isn't pretty, because then everything is red:

  $ LS_COLORS='ex=1;31:ln=target' ls -log --color slink x.exe
  lrwxrwxrwx 1 5 Apr 14 17:19 slink -> x.exe     (red, red)
  -rwxr-xr-x 1 0 Apr 14 17:19 x.exe              (red)

At first I considered changing the meaning of ln=target so that
with -l, ls would stat only the RHS of the "->" for a symlink.
But if you do that, there's no way to specify how to color the
symlink on the LHS.

This is looking like a feature request, and an opportunity
to better document the current state of affairs.

Suggestions welcome, even if not accompanied by a complete
patch.  I don't expect to address this for the upcoming release.