bug#12445: ls --color does not color symlinks when not resolving them

[Jim Meyering]

Pádraig Brady wrote:
...
>> ls 8.10 doesn't have the issue, and when I tested the latest version
>> I only did so with -l which also doesn't show the issue.
>>
>> So this regression was added since 8.10 and only when -l is not used.
>>
>> I'll add tests etc. and apply a fix in your name.
>
> So the regression was introduced in coreutils 8.14 in:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=84457c49
  http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=c5ccf29bb
>
> I dug a little deeper and was confused as to the need
> for the simulated "linkok" at all. That was originally introduced with:
> http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/10608/focus=10927
>
> I also noticed that is_colored() was not used with C_ORPHAN,
> thus meaning any of or=00, or=0, or= in LS_COLORS was considered significant.
> One could argue that for any attribute, 00 should mean color as 00,
> rather than don't color, but for consistency with all other color checks
> I changed that to use is_colored(). As that was the only part of the
> code inspecting
> the "linkok" variable, I removed the simulated linkok referenced
> in the above link.
>
> All tests pass with the new code.
>
> cheers,
> Pádraig.
>
> From ebf697b623435d46dd48998408e1c7cf3eba1623 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?P=C3=A1draig=20Brady?= <address@hidden>
> Date: Sun, 16 Sep 2012 04:10:50 +0100
> Subject: [PATCH] ls: fix coloring of dangling symlinks in default listing
>  mode
>
> When listing a directory containing dangling symlinks,
> and not outputting a long format listing, and orphaned links
> are set to no coloring in LS_COLORS, then the symlinks
> would get no color rather than reverting to the standard
> symlink color.  The issue was introduced in v8.13-19-g84457c4
>
> * src/ls.c (print_color_indicator): Use the standard method
> to check if coloring is specified for orphaned symlinks.
> The existing method would consider 'or=00' or 'or=0' as significant
> in LS_COLORS. Even 'or=' was significant as in that case the
> string='or=' and the length=0.  Also apply the same change
> for missing symlinks for consistency.
> (gobble_file): Remove the simulation of linkok, which is only
> tested in print_color_indicator() which now handles this directly
> by keying on the LS_COLORS values correctly.
> * tests/misc/ls-misc.pl: Add a test case.
> * THANKS: Add the reporter.
> * NEWS: Mention the fix.
> Reported-by: David Matei
> ---
>  NEWS                  |    4 ++++
>  THANKS.in             |    1 +
>  src/ls.c              |   11 ++---------
>  tests/misc/ls-misc.pl |   15 +++++++++++++++
>  4 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 2e69391..ab205f5 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -21,6 +21,10 @@ GNU coreutils NEWS                                    -*- 
> outline -*-
>    numbers, and up to 8 times slower for some worst-case individual numbers.
>    [bug introduced in coreutils-7.0, with GNU MP support]
>
> +  ls now correctly colors dangling symlinks when listing their containing
> +  directories, with orphaned symlink coloring disabled in LS_COLORS.
> +  [bug introduced in coreutils-8.14]

Thanks for digging into that.  I confirm it solves the problem,
and the test would fail without the ls.c patch.

Your commit looks perfect.