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/
