Eric Blake <[EMAIL PROTECTED]> wrote: > Eric Blake <ebb9 <at> 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 >> to investigate further. > > 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/msg00004.html > http://lists.gnu.org/archive/html/bug-coreutils/2007-07/msg00079.html > > It looks like when -l is NOT in effect, you should not stat the result of a > symlink. But when -l IS in effect, and C_EXEC is enabled, then the result of > stat'ing the symling IS used, in order to color the symlink target differently > than the color of the symlink.
Hi Eric, Thanks for investigating that. However, it's not really a regression. The stated goal of that change was to avoid stat'ing through symlinks. If you really want to stat through them anyhow (which might cause a hang (stale mount) or spin up a an idle disk), you can use the special "ln=target" directive. However, maybe we need a new option: With the latest coreutils, I get this without "-l": $ LS_COLORS='ex=1;31:ln=5;32' ls --color slink x.exe slink x.exe (green, red) and same with coreutils-6.9. So far so good. But as you say, the difference is with -l. [prepare: touch x.exe; chmod a+x x.exe; ln -s x.exe slink] With coreutils-6.9: $ LS_COLORS='ex=1;31:ln=5;32' /cu/6.9/bin/ls -log --color slink x.exe lrwxrwxrwx 1 5 Apr 14 17:19 slink -> x.exe (green, red) -rwxr-xr-x 1 0 Apr 14 17:19 x.exe (red) With latest: $ LS_COLORS='ex=1;31:ln=5;32' ls -log --color slink x.exe lrwxrwxrwx 1 5 Apr 14 17:19 slink -> x.exe (green, *none*) -rwxr-xr-x 1 0 Apr 14 17:19 x.exe (red) Using the latest with ln=target isn't pretty, because then everything is red: $ LS_COLORS='ex=1;31:ln=target' ls -log --color slink x.exe lrwxrwxrwx 1 5 Apr 14 17:19 slink -> x.exe (red, red) -rwxr-xr-x 1 0 Apr 14 17:19 x.exe (red) At first I considered changing the meaning of ln=target so that with -l, ls would stat only the RHS of the "->" for a symlink. But if you do that, there's no way to specify how to color the symlink on the LHS. This is looking like a feature request, and an opportunity to better document the current state of affairs. Suggestions welcome, even if not accompanied by a complete patch. I don't expect to address this for the upcoming release. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
