[ANNOUNCEMENT] Updated: coreutils-6.10-1

[Corinna Vinschen]

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
  ex=1;31:ln=5;32:di=1;34

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

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/