GNU bug report logs - #12445
ls --color does not color symlinks when not resolving them

Previous Next

Full log

Message #26 received at 12445 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 12445 <at> debbugs.gnu.org, Matei David <matei <at> cs.toronto.edu>
Subject: Re: bug#12445: ls --color does not color symlinks when not resolving
	them
Date: Sun, 16 Sep 2012 10:45:06 +0200

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?= <P <at> draigBrady.com>
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.