[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Displaying Unix file information in DIRED
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: firstname.lastname@example.org (Stephen L. Nicoud)
Is there a way to modify Zmacs' DIRED so that it displays the
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).
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).
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
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
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.
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.
(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.