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?= <[email protected]> > 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.
