Re: ls -lF dereferences symbolic links - ?bug or feature?
Eric J Haywiser [EMAIL PROTECTED] writes: I would expect the 2nd command to behave like this: [EMAIL PROTECTED] ~/coreutils-5.3.0/src/ls -lF total 1 -rwxr-xr-x exe* lrwxrwxrwx n@ - nonexistant lrwxrwxrwx x@ - exe I can see your point: that would be logical, and it seems to be consistent with what POSIX requires. POSIX http://www.opengroup.org/onlinepubs/009695399/utilities/ls.html says that -F is not supposed to follow symbolic links, and if that is the case then coreutils is incorrect to output x - exe* in the last line (where the * is derived by following the symlink). However, POSIX is not entirely clear in this area, as its formats for ls -l outputs don't specify where the -F decorations are to be placed. Also, this is longstanding behavior, both in coreutils and in traditional UNIX. For example, on Solaris 9: $ touch exe; chmod 755 exe $ ln -sf nonexistant n $ ln -sf exe x $ /usr/xpg4/bin/ls -lF total 4 -rwxr-xr-x 1 eggert eggert 0 May 20 14:27 exe* lrwxrwxrwx 1 eggert eggert11 May 20 14:28 n - nonexistant lrwxrwxrwx 1 eggert eggert 3 May 20 14:28 x - exe* Also, there is a usability argument for the traditional behavior in common use. First, the @ - is redundant; anything with an arrow must be a symbolic link, so there's little point to the @. Second, it's useful for people to see the type of file the symbolic link is pointing to. I suspect that this is a bug in POSIX, since it is vague and in at least one spot is specifying behavior that is contrary to common practice. Perhaps you can take this up with the POSIX committee by filing an Aardvark? http://www.opengroup.org/austin/defectform.html In the mean time I'm afraid that I'm inclined to let sleeping dogs lie. There is a similar issue with ls -lp. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -lF dereferences symbolic links - ?bug or feature?
Paul, Thank you for your reply. Eric J Haywiser [EMAIL PROTECTED] writes: Apparently ls -lF classifies the link reference rather than the link itself, while ls -F classfies the link. On Thu, 12 May 2005, Paul Eggert wrote: Paul I don't observe this behavior with coreutils 5.3.0 ls. Paul Perhaps the bug has been fixed since your version? Please try: Paul Paul ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz I have done so, and continue to observe this behavior. Please see transcript below. Have I perhaps used incorrect terminology, or otherwise failed to communicate my observation? Please advise. [EMAIL PROTECTED] ~/coreutils-5.3.0/src/ls --version ls (GNU coreutils) 5.3.0 Written by Richard Stallman and David MacKenzie. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED] ~/coreutils-5.3.0/src/ls -l total 1 -rwxr-xr-x exe lrwxrwxrwx n - nonexistant lrwxrwxrwx x - exe [EMAIL PROTECTED] ~/coreutils-5.3.0/src/ls -lF total 1 -rwxr-xr-x exe* lrwxrwxrwx n - nonexistant lrwxrwxrwx x - exe* [EMAIL PROTECTED] ls -F exe* n@ x@ I would expect the 2nd command to behave like this: [EMAIL PROTECTED] ~/coreutils-5.3.0/src/ls -lF total 1 -rwxr-xr-x exe* lrwxrwxrwx n@ - nonexistant lrwxrwxrwx x@ - exe and then would further expect [EMAIL PROTECTED] ~/coreutils-5.3.0/src/ls -lF --dereference total 1 -rwxr-xr-x exe* lrwxrwxrwx x* ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -lF dereferences symbolic links - ?bug or feature?
Eric J Haywiser [EMAIL PROTECTED] writes: Apparently ls -lF classifies the link reference rather than the link itself, while ls -F classfies the link. I don't observe this behavior with coreutils 5.3.0 ls. Perhaps the bug has been fixed since your version? Please try: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
