On Jul 22, 10:52pm, Greg A. Woods wrote:
} [ On Wed, July 22, 1998 at 01:58:31 (-0700), "Erik E. Fair" (Timekeeper) wrote: ]
} >
} > Of course, we should also be careful to avoid feeping creaturism;
} > otherwise we'll end up with a monstrosity like "lp".
} 
} 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.  :->

} only gets ugly when you graft lpr on the side and have two different
} kinds of network attachments, but that's not the lp I'm talking about.

     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.

} Lpr's only "advantage" is a single common configuration file in the form
} of a termcap-style database of barely descriptive attributes and flags.

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

} Lp is a bit more difficult to configure because information is more

     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.

}-- End of excerpt from Greg A. Woods