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