bug-coreutils
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]