Re: coreutils regression in ls: link color "target"

[Bob Proulx]

Kirk Kelsey wrote:
> the color support in ls for using "target" as the link color has  
> regressed with revision 1.421 of coreutils.

Thank you for your report.  But the version number 1.421 does not map
to any known version of coreutils.  Please double check your version
number.  You can get the version of ls with --version.

  ls --version

The current version of coreutils is 6.9.

> Previously one could have a sym link colored the way its target
> would be, but now I get "argetm<filename>" and no color. Simply
> reverting the change in 1.421 does restore the capability, but based
> on the cvs log message it also causes unnecessary failures.

Ah, so the 1.421 you are talking about is the cvs version 1.421 of ls.c?

  date: 2006-07-21 08:49:25 +0000;  author: meyering;  state: Exp; lines: +0 -6
  Fix another bug: ls --indicator-style=file-type would call
  stat for a symlink, even though it wasn't always needed.
  In some cases, that unnecessary stat would cause ls to fail.
  * src/ls.c (gobble_file): Don't treat symlinks specially (in
  requiring a stat syscall).  Remove the offending exclusion.
  * NEWS: Mention the fix.
  * tests/ls/stat-dtype: New file/test, for the above fix.
  Also exercises the new df feature, below.

--- ls.c         20 Jul 2006 10:20:23 -0000     1.420
+++ ls.c         21 Jul 2006 08:49:25 -0000     1.421
@@ -2547,12 +2547,6 @@
              && (type == symbolic_link || type == unknown))))
       || (format_needs_type
         && (type == unknown
-
-             /* FIXME: remove this disjunct.
-                 I don't think we care about symlinks here, but for now
-                    this won't make a big performance difference.  */
-                          || type == symbolic_link
-
              /* --indicator-style=classify (aka -F)
                  requires that we stat each regular file
                            to see if it's executable.  */

Which basically means that previously if the type was a symlink stat
through it to find the type of the underlying file.  Now it does not
do that.  I can only give this a cursory glance now but this seems
correct because ls needs to follow the condition of -L being present
or not.  If -L is present then it follows the symlink.  If not then it
should not.  Right?

If possible could you create a small test case that illustrates the
behavior you are seeing that would show us both what you see and what
you want to see?

Thanks
Bob