[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: printing to a unix box
Date: Wed, 3 Oct 90 16:39 EDT
From: Bruce R. Miller <miller@GEM.cam.nist.gov>
Date: Thu, 20 Sep 90 16:16 EDT
From: barmar@Think.COM (Barry Margolin)
Date: Thu, 20 Sep 90 11:21:47 EDT
From: olson@juliet.ll.mit.edu
Thats correct, of course, but there is much simpler way to load the
unix-lpd software. Unix-lpd really has nothing to do with RPC, nothing
to do with Embedding-Support, and nothing to do with UX-Support. Just
load it (the file sys;embedding;ux;unix-lpd) on top of IP-TCP.
This also applies to the unix-rsh and unix-tape software which can
be found in the same directory. (Famous last words: I have compiled and
loaded unix-lpd in the manner described, but I haven't actually used it.)
This is probably true. However, there's lots of good stuff in RPC,
Embedding-Support, and UX-Support, and much of it has little to do with
embedded systems, except that embedded systems require them. If you
have Lispms sharing a network with Suns you'll almost certainly find
uses for the stuff in these systems.
barmar
Actually, on my XL400 (8.0.1, which has the three systems already
loaded) I get the impression that unix-lpd is NOT included in any of
these systems and must be loaded separately anyway. I had to do what
olson did.
Unix-lpd isn't defined in any of those systems, it is defined in the
Hardcopy system. However, the module is declared with a
(:required-systems :ux-support) clause, which causes its loading to be
postponed until after the UX Support system is loaded.
On my 3640 I never manually loaded the unix-lpd file. When I loaded UX
Support it was loaded automatically.
Also, although there is a server for :unix-rsh implemented in
sys...us;unix-protocols, there is no protocol defined for it. One plus
with rsh is that it can be made to NOT ask for passwords (at least twixt
unix boxes), whereas rexec ALWAYS asks (it doesn't make use of a
connection which lives longer than the individual request like ftp does,
so it doesnt remember the password).
I have an implementation of :unix-rsh; it depends on some patches to TCP
to support use of low-numbered source ports. Note that if you are at
all security-conscious, allowing RSH from Lispm clients is a humongous
security hole, since Lispms have no way of preventing impersonations.
It shouldn't be too hard to patch REXEC to remember the password (I've
suggested to Symbolics that FS:*REMEMBER-PASSWORDS* should affect
REXEC). You could also remember the passwords in the code that invokes
:UNIX-REXEC, since there's a :PASSWORD argument to the service.
Alternatively, I believe it signals the FS:LOGIN-REQUIRED condition when
a username or password is needed, so you can wrap a CONDITION-BIND
around your code and use (DBG:PROCEED <condition> :PASSWORD <password>).
On the other hand, although
rexec, as implemented, does not arrange for a bi-directional stream, I
hacked up some code which marginally does (and I mean `hacked' in a
negative sense). This allows me to run LaTeX on the sun w/o using
Terminal, see the output and answer its goofy questions (there is, of
course, a little problem with appropriate ined & echoing :<) Is there a
better way?
The :UNIX-REXEC protocol does create a bi-directional stream. But it's
a pain to use for automating interactive programs because it can be hard
to tell when the remote program is done. But I'm not sure what your
hacked up code can do that would solve this problem. What's wrong with
using Terminal, anyway?
As we do have a bunch of Suns around here and a superficial browsing of
the aforementioned systems didn't flash any lightbulbs above my head;
Can anyone enlighten me as to what useful things I might find there?
Well, except for UNIX-PROTOCOLS.LISP, most of the stuff in UX-Support is
UX400-specific (although I imagine it might be possible, and would be
nice, to get the run-bar stuff working on any X remote screen, not just
a UX400 main screen). In Embedding-Support, KEYBOARDS.LISP is useful
for anyone using X Remote Screen (it defines keyboard layouts for
several consoles that are likely X servers). RPC and RPC Development
are useful if you want to implement new protocols using Sun RPC rather
than using TCP or UDP directly.
barmar