[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ls -Fl -- no @ on symlinks?
From: |
Bob Proulx |
Subject: |
Re: ls -Fl -- no @ on symlinks? |
Date: |
Fri, 9 Jul 2004 14:20:26 -0600 |
User-agent: |
Mutt/1.3.28i |
Jim Meyering wrote:
> address@hidden (Bob Proulx) wrote:
> > One of the folks at work called to my attention that 'ls -Fl' prints
> > identifying characters at the end of the file for everything but not
> > for a symlink.
> >
> > lrwxrwxr-x 1 rwp esl 3 Jul 5 23:02 bar1 -> foo
> > lrwxrwxr-x 1 rwp esl 7 Jul 5 23:09 bar2 -> somedir/
>
> As I recall, the final type indicator is intended to tell you the type
> of the ultimate referent -- that is, the result of `stat'ing the symlink.
I have not done an exhaustive analysis of the different ways it is
printed. And this is not important enough to me at the moment to try.
I am just going to let it sit and simmer for a while. But it seems
inconsistent to me. I am talking about the HP-UX ls in addition to
the GNU ls here.
I think what you just said is this, 'ls -F' prints the @ on dangling
symlinks. Because otherwise if you stat the file you would never see
an @ because it would never be reported as a symlink in other cases.
That would be consistent. But that is not what seems to happen.
ls --version | head -n1
ls (coreutils) 5.1.3
mkdir foodir
ln -s foodir bardir
ls -F bardir
bardir@
ls -Fl bardir
lrwxrwxr-x 1 rwp esl 6 Jul 9 14:00 bardir -> foodir/
In the 'ls -F' case we get an @. In the 'ls -Fl' case we get a '/'.
That seems inconsistence to me.
I like your definition of saying that the classifier character is
always the result of stat() on the file. A very simple rule to always
apply. Then I suppose we would only see an @ if the stat fails.
> I think that such an `@' would be redundant, coming just before
> the `->' indicator. Solaris 5.9's /bin/ls also does not display
> the `@' there. Why waste valuable screen real estate?
You have a strong argument for the @ being redundant since you can
clearly see the -> there. You have convinced me.
Just fyi but this is the HP-UX output.
HP-UX 10.20: /bin/ls -F bardir
... no result is printed ...
HP-UX 11.0: /bin/ls -F bardir
bardir@
HP-UX: /bin/ls -F | grep bardir
bardir/
HP-UX: /bin/ls -Fl bardir
lrwxrwxr-x 1 rwp esl 6 Jul 9 14:00 bardir@ -> foodir
A different behavior that is inconsistent in a different way. Almost
exactly the opposite. But not quite because the @ is applied to the
source instead of the / to the destination in the long listing. I
definitely like the GNU ls behavior better here.
And 10.20 prints nothing in the case of having it directly on the
comand line which was apparently a bug fixed in 11.0. Just a
curiosity now.
> I suppose it might make sense to put an @ (or some other indicator)
> there to indicate it's a dangling symlink, but would it be worth it?
We are down into very small points anyway. So a discussion of whether
it is worth it is definitely going to end up as not really. But on
the principle of being consistent I think the 'ls -F' output should
not print an @ as it does now but instead print the result of the
stat() as it does for 'ls -l'.
Bob