Re: [ANNOUNCEMENT] Updated: coreutils-6.10-1

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> Eric Blake <ebb9 <at> byu.net> writes:
>> 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.
>
> And I believe this patch fixes things.  I don't know if Corinna wants to be
> mentioned in THANKS (she's been generally reluctant to expose her email 
> address
> on the cygwin lists); hence the obfuscated address in the log message for now.
>
>>From ff17266b281a93adafd9ac2484d9836e8d1c97a1 Mon Sep 17 00:00:00 2001
> From: Eric Blake <address@hidden>
> Date: Mon, 14 Apr 2008 11:14:00 -0600
> Subject: [PATCH] Fix ls -l coloring regression from 2007-07-15.

Thanks, but I'd like to retain the default (a deliberate "feature" ;-)
that ls -l --color does not stat the referent of each symlink it encounters.

>From reading the comments, you can guess that this behavior change was
deliberate.  Sorry I didn't make it clearer.  Dereferencing symlinks
just to color them is highly undesirable (at least in some environments),
hence the change so that ls --color no longer does that by default.
The marginal benefit of coloring the RHS was outweighed by the potential
negative impact of the additional stat calls.

I think we'll need some new LS_COLORS-specified option to
reenable coloring of the symlink referent in a long listing.