Subject: Re: lpd and filter programs
To: Greg A. Woods <email@example.com>
From: John Nemeth <firstname.lastname@example.org>
Date: 07/28/1998 23:06:35
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
} 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