Subject: sysV lp (was: Re: /etc/default)
To: matthew green <mrg@mame.mu.Oz.Au>
From: Simon J. Gerraty <sjg@frodo.dn.itg.telecom.com.au>
List: current-users
Date: 07/31/1995 13:47:40
>    believe it or not a _decent_ implementation of the SysV lp system
>    would be a third (but that's another thread).
> 
> *why* ?

Note the underlined _decent_,  I'm yet to see one :-)

> i'm like, totally in shock that i've finalkly heard of someone who
> likes this.

Hmmm, I don't so much like lpadmin - most vendors have made it _far_
more complex than it needs to be.  If they'd just adequately document
how the system hangs together...  As for lpsched, on most sysV
machines its totally brain dead...

So, I do not like any of the implementations of lp that I've seen so
far, but I _do_ like the concept and the flexibility that it offers.

Having had to implement printer interfaces from mainframes (UTS
actually) to, ftp sessions on PC's, to X.25 gateways and a few other
weird things, the idea of an interface script is appealing.

Yes you can do some of these tricks with lpr, by making a filter
script do all the work, but its much harder because the filter script
is not invoked with any really useful arguments (as I recall).  By
contrast the lp interface script is told just about everything it
needs to go and look up private data bases about printer details etc
etc etc.  Some people hate the complexity - I like the flexibility.

The other area where lp wins over lpr is the ability to setup multiple
printers serving the same queue.  Obviously this is only of interest
to EDP departments and the like...  I'm sure lpd could be made to do
this - though I've never tried.

Where lpr/lpd seriously wins over lp, is decent support for the
concept of remote printers.  Its only svr4 that has added this concept
to lp...  well Solaris anyway - and everything I've heard says
printing on Solaris is flakey...

That wouldn't be a surprise.  From memory, the svr3 lpsched is totally
stupid when it comes to handling errors from interface scripts.  The
script has to actually kill itself to make lpsched pay attention.

Still the interface script has the opportunity to disable the queue or
do anything else required.  I've written interface scripts that worked
around all the stupidity of svr3's lpsched.

If we added the idea of an interface script that got called with
enough args so that it knew who/what why it was doing, then lpd would
be cool.

Of course removing the need for lpr to setuid root would be good too.

--sjg