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. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
