🚀 go-pugleaf

ls in fileutils 3.2 doesn't handle symbolic links quite right.  If you
do the following:
    mkdir foo
    ln -s bar foo
    ln -s bar quux
    ls quux
you get
    quux
whereas you should get a listing of the (zero) files in foo.

I made the following change to get the correct behaviour.  I don't
know if this is the right solution, since I couldn't quite figure out
what this code was supposed to do.

--- ls.c.old	Mon Mar  9 00:46:29 1992
+++ ls.c	Mon Apr 13 21:20:07 1992
@@ -943,7 +943,7 @@
 	  /* Stat the file linked to; automatically trace it in non-long
 	     listings, get its mode for the filetype indicator in long
 	     listings. */
-	  if (linkpath && lstat (linkpath, &linkstats) == 0)
+	  if (linkpath && stat (linkpath, &linkstats) == 0)
 	    {
 	      if (S_ISDIR (linkstats.st_mode)
 		  && explicit_arg && format != long_format)

Even with this change, ls -lF handles symbolic links differently from
the Ultrix 4.0 ls.  Doing an ls -lF bar with the Ultrix ls gives
    lrwxrwxr-x  1 ian             3 Apr 13 21:34 bar@ -> foo
but the GNU ls gives
    lrwxrwxr-x   1 ian      users           3 Apr 13 21:34 bar -> foo/
Note that the Ultrix ls applies the -F to bar rather than foo.
I think the GNU method is better.

Without the patch above, ls -lF quux gives
    lrwxrwxr-x   1 ian      users           3 Apr 13 21:34 quux -> bar@
With the above patch, ls -lF quux gives
    lrwxrwxr-x   1 ian      users           3 Apr 13 21:34 quux -> bar/
I don't know which result is desirable.
-- 
Ian Taylor                     ian@airs.com                    uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``Do you make a grievance of weighing so many pounds only, instead of three
  hundred?  Then why fret about living so many years only, instead of more?''