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

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Matei David <matei <at> cs.toronto.edu>
Cc: 12445 <at> debbugs.gnu.org
Subject: bug#12445: ls --color does not color symlinks when not resolving them
Date: Sun, 16 Sep 2012 04:46:46 +0100

[Message part 1 (text/plain, inline)]

On 09/15/2012 11:40 AM, Pádraig Brady wrote:
> reopen 12445
> stop
>
> On 09/15/2012 03:28 AM, Matei David wrote:
>> On Sat, 15 Sep 2012 00:55:12 +0100
>> Pádraig Brady<P <at> draigBrady.com> wrote:
>>
>>> tag 12445 + notabug
>>> close 12445
>>> stop
>>>
>>> On 09/14/2012 05:54 PM, Matei David wrote:
>>>> When the ORPHAN property is disabled in dircolors, ls --color does not
>>>> stat() symlinks. However, in this case symlinks are not colored using the
>>>> LINK property.
>>>>
>>>> How to reproduce:
>>>> $ eval $(dircolors -p | sed 's/^ORPHAN.*/ORPHAN 00/' | dircolors -)
>>>> $ mkdir /tmp/xxx
>>>> $ ln -s /tmp/nowhere /tmp/xxx/yyy
>>>> $ ls --color /tmp/xxx
>>>>
>>>> Expected output:
>>>> yyy, colored cyan (default for LINK)
>>>>
>>>> Actual output:
>>>> yyy, not colored
>>>>
>>>> Fix attached. Basically, in gobble_file(), assume a symlink is ok if stat()
>>>> is not run on it.
>>>
>>> It seems this was fixed over 5 years ago in version 6.9
>>> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=0a744370
>>> Are you using an older version than that?
>>>
>>> I'm marking as done for now.
>>>
>>> thanks,
>>> Pádraig.
>>
>> I'm using coreutils 8.19. There are 2 lines which ever modify f->linkok (both
>> set it to true): 2700 and 2720. Both are inside the if block starting at
>> line 2560. By design, the if block is _not_ executed under the conditions I laid
>> out above in order to avoid both fstat() and stat() calls on the symlink (which
>> is ok!) However, the coloring is missing. Did you try my code?
>>
>> The bug you mention was about avoiding the stat() call, i.e. following the
>> link. There is also this one, related:
>> http://git.savannah.gnu.org/cgit/coreutils.git/commit/src/ls.c?id=a085b6fc6c8fa03dac20f01f2f2b64b50b8bdf66
>>
>> The behaviour I observe is: no fstat(), no stat(), (great so far...) but no
>> color either- that's the bug.
>
> Drats, I was too hasty sorry.
>
> 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

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.

[ls-linkok.diff (text/plain, attachment)]

Previous Next

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