Jim Meyering meyering.net> writes:
>
> 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
Eric Blake <[EMAIL PROTECTED]> wrote:
> Eric Blake 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.
Eric Blake 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/msg0
Eric Blake 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding bug-coreutils]
According to Corinna Vinschen on 4/11/2008 11:10 AM:
|
| I think I just found a bug in ls(1) from the latest coreutils 6-10-1.
|
|
| I have a custom LS_COLORS setting:
|
| $ echo $LS_COLORS
| ex=1;31:ln=5;32:di=1;34
|
| Non
