Displaying Unix file information in DIRED

[Reti@STONY-BROOK.SCRC.Symbolics.COM (Kalman Reti)]

    Date: Sat, 21 Jul 90 17:52 EDT
    From: Barry Margolin <barmar@Think.COM>

	Date: Sat, 21 Jul 90 12:56 PDT
	From: Reti@STONY-BROOK.SCRC.Symbolics.COM (Kalman Reti)

	    Date: Fri, 20 Jul 90 21:07 PDT
	    From: snicoud@atc.boeing.com (Stephen L. Nicoud)

	    Is there a way to modify Zmacs' DIRED so that it displays the
	    protections, 
	This is easy, since FS:DIRECTORY-LIST already returns a :PROTECTION
	field (at least for FTP, I don't have an NFS host to try it on).  

    Why don't you have an NFS host to try it on?  There must be at least one
    UX400S there at Symbolics.
The existence of a UX400S isn't germaine; its the existence of a Unix host
running NFS on which I have an account (or know the password) which is lacking.
If you know of any hosts on the Internet that allow anonymous NFS mounting,
that would suffice as well.  I don't know of any (the one I used to use stopped
allowing it several months back).
									  All
	that is necessary is to modify the file lister to print it (code example
	provided below).  Any other information that is returned in the property
	list is similarly a snap to add (I have a private patch that returns the
	LMFS partition id, for example).
			 group ownership 
	This is currently not returned by FS:DIRECTORY-LIST (via FTP, again I
	can't test NFS).  This is because we don't parse it in the FTP response
	to a LIST command; I've been told that there is a great variability in
	what comes back from various hosts' FTP servers since the format is 
	intended to be viewed by humans instead of programs.  The comments in the
	source code for the Unix directory list parser indicate
	that the group field is only present sometimes, but assuming you deal only
	with hosts that provide it, I've also included the trivial change below.

    The most common Unix FTP server will only include the group name if the
    LIST command is invoked with the "-g" option (it simply passes the LIST
    argument as arguments to the Unix "ls" command).  I believe the 8.1 Unix
    FTP client includes my changes to directory listing that supports
    passing options.
It does.  However, many hosts on the Internet seem to return the group even in
the absence of this flag.  As I mentioned above, I'm no Unix wizard, I just wanted
to point out how the petitioner could get the end-result he wanted.

	It took a total of about 5 minutes to find which functions to modify on
	my machine, and probably another 5-10 minutes to modify them and test
	them.

    Then how come you did it the way you did?  As you must have noticed in
    your investigation, the directory list formatter is called through the
    variable ZWEI:*DIRECTORY-SINGLE-FILE-LISTER*, so instead of modifying a
    function you should write a new function (which could be a modified
    version of the original function) and set the variable to this.  
Well, yes and no.  There's a tradeoff here.  Since the change is in the
middle of a function, the original and the copy would have to share a lot
of code which then would need to be kept in synch if the original ever changed.
In my experience it is harder to do this if you use a separate function; if
you redefine the real function, the system at least keeps track of the fact
that it has been modified.  There aren't any mechanisms for saying "flag
this function if this other one has changed", which is what I'd want.

Of course your way would work too; it also has the advantage (if you are
consistent in always using that approach) in being 'undoable' simply by
typing (unadvise).  I guess I feel that it's close to a toss up.

However, the REAL reason I did it this way is that in the world I'm using
there are two direct callers of ZWEI:DEFAULT-LIST-ONE-LINE (i.e. not through
the hook variable).  One could debate whether or not this constitutes a bug
(there are arguments on both sides), but it makes a hook-based change less
desirable since it wouldn't appear in the FSEdit listing of a Unix directory,
only in the Dired and CP command listings.

								     My
    general rule is: only modify a function as a last resort.  In this case
    there's a hook variable, and frequently you can accomplish what you want
    by using SI:ADVISE-PERMANENTLY.
Again, in this case, only by copying the entire body of code you are 'advising'.
That seems philosophically more like a replacement than advice to me.  If there
were an "advise at this PC" mechanism, then I'd agree with you.

		     ;; Group
		     (add-property :group (pop tokens))

    Symbolics NFS calls this property :ACCOUNT, not :GROUP, presumably for
    consistency with the TOPS-20 support.
OK, I didn't know that.  This patch should probably be updated to call it 
the same thing.  I intended it only as a general guideline anyway (though
a re-reading of my original message reveals I failed to state that explicitly;
that's what you get when you're in a hurry  ;-< ).

    I sent my version of the patch that does to this to Stephen under
    separate cover (since it includes modified Symbolics code, and I don't
    have the right to publish that to SLUG).
Oops, technically, I probably didn't have the right to do it either (since
I just now noticed that one of the functions is in the optional sources).
I could have sworn that the one file listing function was in basic source
some time back, since I modified it at a customer site without optional
sources.  Maybe my memory is going as I get older.

						    barmar