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