Eric Blake <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
