bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pádraig Brady
Subject: bug#12445: ls --color does not color symlinks when not resolving them
Date: Sat, 15 Sep 2012 11:40:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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<address@hidden>  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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]