[ On Tue, July 28, 1998 at 23:06:35 (-0700), John Nemeth wrote: ]
> Subject: Re: lpd and filter programs
>
> On Jul 22, 10:52pm, Greg A. Woods wrote:
> } I think you've got things backwards.  Lpr is a monstrosity.  Lp is quite
> } simple and elegant.  At least from an implementation point of view.  Lp
> 
>      Let's see:  lpr, lpq, lprm, lpc vs. lp, lpshut, lpsched, lpmove,
> lpsystem, enable, disable, lpstat, accept, reject, cancel.  Most of
> the commands in the latter group have a gazillion options.  Yep, it's
> real elegant.  :->

That's a very lame comparison and does no justice to either system.

>      lp doesn't have a native network attachment.  Some lp systems use
> rsh (ugh!), some use the lpr protocol, some do their own thing, and
> some do multiple things.

Ah, well, it depends on exactly which version you're talking about.....

If we assume the POSIX version (did it ever actually get approved?) is
standard, then yes, it does have the possiblity of a network interface.

>      Add in the simple command interface, and a standarised method of
> handling remote printers.  Both of which I consider to be big
> advantages.

What the heck are you talking about????  From the *user's* point of view
there's little or *NO* difference between the command-line interfaces of
lpr(1) and lp(1) for trivial usage.  In fact I'd claim lpr(1) is *more*
complex if you compare any of the normal human factors measurements.

>      This is a gross understatement.  I've configured both lp and lpr
> for both local and remote printers.  lpr is simple to setup and
> maintain.  lp is a royal pain in the butt.

I dunno -- I've always spent more time getting lpr to work right than lp.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>