bug-coreutils
[Top][All Lists]
Advanced

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

Re: [anonymous] [bugs #11124] ls stats symbolic link targets (fwd)


From: Mark H. Wilkinson
Subject: Re: [anonymous] [bugs #11124] ls stats symbolic link targets (fwd)
Date: Mon, 29 Nov 2004 19:54:15 +0000

Bob Proulx wrote:
> Since that bug was posted anonymously I don't see how any reasonable
> discussion can make it back to the original bug poster.  Sigh.

Apologies - I posted the bug without realizing that I hadn't identified
myself to savannah. Thanks for the pointer you attached to the bug.

> [snip some discussion of symlinks to NFS directories, which I've taken
> onboard]

> >   I can imagine this being intolerable on systems where /home is
> >   full of links to host:/export/home/user, which I believe to be
> >   fairly common practice.
> 
> Hmm...  I don't think I would call that common practice.

Hmm; I thought I recalled Solaris 8 leaning in that direction for
workstation users: each user has their home directory on the local disk,
but can login to other machines if needed. It's been a while though.
Perhaps that only works for small networks too...

> [snip discussion of supplying --color as a system-wide default,
> again taken onboard]

> I believe that ls --color will paint symlinks differently depending
> upon whether they are symlinks to files or symlinks to directories.
> Therefore the target of the symlink must be stat'd.

I've done a bit more digging, because this was the guts of what I
considered to be the problem. You're right that 'ls --color' will paint
the links differently, but only if the LS_COLORS option for LINK is set
to 'target' (from reading the output from 'dircolors -p'). The standard
setup on Red Hat just paints all symlinks in pale blue, though, hence me
thinking that stat'ing the link target was redundant.

I can see it's a fairly limited corner case, though - by the sound of it
you need to be on a Red Hat derivative with a somewhat ill-advised usage
of symlinks and NFS.

> >   I can see that the behaviour of 'ls -l' in this regard is at least
> >   debatable.
> 
> Debate would need a suggestion as to how 'ls -l' can avoid calling
> stat() on the file.  I don't think it is debatable until such a
> suggestion is made.

The debate I was imagining was between ls having a policy of only
looking at the local directory, or ls looking at whatever is necessary
to produce the output detail the user has asked for. ls goes for the
latter option, applying color to both the link and the link target in
the output it produces when asked. It's conceivable that 'ls -l' could
produce partially colored output, stat'ing the links but not the link
targets (and hence not coloring the link target either).

But this is probably a debate that happened years ago and my intention
wasn't to reopen it. The comment was there because I could understand
why 'ls -l --color' currently needs to stat link targets. I couldn't see
why 'ls --color' was needing to do it too, given that there was no
information about the link target in the output I was seeing. So, going
back to your first comment, I wasn't asking for ls to tell me anything
about the link targets, and yet it was going and looking. A limited case
perhaps, particularly as changing LS_COLORS can change what the user is
asking to see, but I thought it worth raising as an issue.

> Sorry for the rant...

No problem: I value the feedback :-)

-Mark.





reply via email to

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