This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Updated: coreutils-6.10-1
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 11 Apr 2008 19:10:48 +0200
- Subject: Re: [ANNOUNCEMENT] Updated: coreutils-6.10-1
- References: <announce.47A62BF1.email@example.com>
- Reply-to: cygwin at cygwin dot com
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html