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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12445 in the body.
You can then email your comments to 12445 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Matei David <matei <at> cs.toronto.edu>
To: bug-coreutils <at> gnu.org
Subject: ls --color does not color symlinks when not resolving them
Date: Fri, 14 Sep 2012 12:54:51 -0400

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

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.

Thanks,
M

[fix (application/octet-stream, attachment)]

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

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

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.

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

From: Matei David <matei <at> cs.toronto.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 12445 <at> debbugs.gnu.org
Subject: Re: bug#12445: ls --color does not color symlinks when not
	resolving them
Date: Fri, 14 Sep 2012 22:28:06 -0400

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.

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

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

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.

thanks!
Pádraig.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Matei David <matei <at> cs.toronto.edu>
Cc: 12445 <at> debbugs.gnu.org
Subject: Re: 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)]

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.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
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:52:59 +0200

On 09/16/2012 05:46 AM, Pádraig Brady wrote:

> +++ b/tests/misc/ls-misc.pl
> @@ -263,6 +263,21 @@ my @Tests =
>        {POST => sub {unlink 's' or die "s: $!\n";
>                      restore_ls_colors; }},
>       ],
> +     # The code related to the above fixes introduced a regression,
> +     # that was fixed after coreutils-8.19.

What did you want to say by this?

Have a nice day,
Berny

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

From: Jim Meyering <jim <at> meyering.net>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 12445 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>,
	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 11:03:05 +0200

Bernhard Voelker wrote:

> On 09/16/2012 05:46 AM, Pádraig Brady wrote:
>
>> +++ b/tests/misc/ls-misc.pl
>> @@ -263,6 +263,21 @@ my @Tests =
>>        {POST => sub {unlink 's' or die "s: $!\n";
>>                      restore_ls_colors; }},
>>       ],
>> +     # The code related to the above fixes introduced a regression,
>> +     # that was fixed after coreutils-8.19.
>
> What did you want to say by this?

I understood it as:

    The patch associated with the above test case introduced a
    regression, which was fixed after coreutils-8.19.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jim Meyering <jim <at> meyering.net>
Cc: 12445 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigBrady.com>,
	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 11:14:42 +0200

On 09/16/2012 11:03 AM, Jim Meyering wrote:
> Bernhard Voelker wrote:
> 
>> On 09/16/2012 05:46 AM, Pádraig Brady wrote:
>>
>>> +     # The code related to the above fixes introduced a regression,
>>> +     # that was fixed after coreutils-8.19.
>>
>> What did you want to say by this?
> 
> I understood it as:
> 
>     The patch associated with the above test case introduced a
>     regression, which was fixed after coreutils-8.19.

so maybe
  s/fixes introduced/introduced/
?

Have a nice day,
Berny

Previous Next

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