This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Hi Eric,

I think I just found a bug in ls(1) from the latest coreutils 6-10-1.

On Feb  3 14:02, Eric Blake wrote:
> [...]
>   ls --color would mistakenly color a dangling symlink as if it were
>   a regular symlink.  This would happen only when the dangling symlink
>   was not a command-line argument and in a directory with d_type support.
>   [introduced in coreutils-6.0]
>   ls --color, (with a custom LS_COLORS envvar value including the
>   ln=target attribute) would mistakenly output the string "target"
>   before the name of each symlink.  [introduced in coreutils-6.0]

These are the changes noted in the changelog.  However, what I see now
is that the target of a symlink is not colored anymore at all.

I have a custom LS_COLORS setting:

  $ echo $LS_COLORS

None of my symlink targets have a color anymore:

  $ ls -l --color=always x.exe y
  -rwxr-xr-x 1 corinna None 529104 Apr  2 13:25 x.exe
  lrwxrwxrwx 1 corinna None      5 Apr 11 18:51 y -> x.exe

According to my LS_COLORS setting, x.exe is printed in red.  After
the "y -> ", the x.exe string is printed in black.

Stracing `ls -l y' shows no stat call for x.exe, which is dubious.

Removing LS_COLORS from my environment does not change that.

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.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]