[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ls -i inefficiency
From: |
Eric Blake |
Subject: |
Re: ls -i inefficiency |
Date: |
Mon, 27 Feb 2006 05:46:00 +0000 |
> 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