Re: ls -i inefficiency

[Eric Blake]

> Good point.  My Solaris 10 host is down right now, but Solaris 9 does
> not complain:
> 
>    54-pete $ ls -l foo
>    lrwxrwxrwx   1 eggert   eggert         7 Feb 26 15:22 foo -> nowhere
>    55-pete $ /bin/ls -L
>    eggert.kshh  foo          savsmtptemp
>    56-pete $ /usr/xpg4/bin/ls -L
>    eggert.kshh  foo          savsmtptemp

I have validated that in 5.3.0, 'ls -L' warned on broken symlinks
encountered implicitly, so it looks like it was between 5.2.1 and 5.3.0
that the behavior changed (unless the Linux box I was using
with 5.2.1 had distro patches that don't match the official
5.2.1 behavior).  However, coreutils has always warned
on broken symlinks on the command line, as evidenced by the
5-year-old tests/ls/follow-slink:

$ ln -s link link
$ ls -L link
ls: link: Too many levels of symbolic links

> 
> OpenBSD 3.4 ls is similar.  So I guess your fix has _removed_ an
> incompatibility rather than added one.  Good show!

So do OpenBSD and Solaris warn when -L appears with an
explicit listing of a broken link?  If so, I think the attached
testsuite patch is sufficient to cover my recent changes.

> 
> I'd write up a NEWS item but I'm not sure when the GNU ls behavior
> changed.

I've been browsing CVS of ls.c to try to spot it myself, but nothing jumped
out on a quick read between revision 1.352 (5.2.1) and 1.406 (CVS head)
as the culprit.  So we'll have to do a separate patch for NEWS, once
we have done more research.

ChangeLog:
2006-02-26  Eric Blake  <address@hidden>

        * tests/ls/inode: Expand to test inode from readdir case.
        * tests/ls/follow-slink: Expand to test broken links encountered
        implicitly, favoring Solaris 9 and OpenBSD 3.4 behavior.

-- 
Eric Blake

coreutils.patch14
Description: Binary data