hazards of linking directories

[Larry Tepper]

We have an 11/70 running V7 here.  Response on the system was
bad enough, and our users were getting frustrated having to wait
minutes just because they needed something like:

	pr *.c | lpr				or
	tbl bunch of files | nroff -ms > output; lpr output

So, we basically rewrote lpr, lpd (and added lpf, the filter which
does the real printing) to our V7 system.  We don't link to files,
but rather put the full pathname of each file into the daemon control
file.  I added a flag so that the line printer filter will do simple
pagination of files (as in the example above, but no columnation).
The line printer filter (lpf) has to be a root-owned setuid program.
Shortly after it starts up, it sets its uid/gid to the originator of
the printing job (using the owner and group of the daemon control
file for the job).  The system also handles multiple printers
and will print over our network (we've been running 3-COM's UNET
for years; and we have a ton of pdp-11's here).

Identical code runs on our 4.1 BSD systems.

I won't apologize to purists who insist that the line printer
shouldn't do pagination.  It already prints a (not so) fancy
banner for you.  95% of the line printer jobs that people used
to run were like the pr example above.  Now they look like

	lpr -p *.c

I would bet that the example I gave is also 95% of what pr is used
for.  Printer jobs now run a LOT faster, they don't bog down the
system when it's already slow, and the code to get it right cost us
all of 40 lines, including handling the -p flag in lpr, defining the
flag in a header file, etc.  In addition, we no longer have to worry
about running out of space in /usr.
-- 
Violence is the last refuge of the incompetent.

{ihnp4 hao philabs sdcrdcf ucbvax!nbires}!stcvax!lat	Larry Tepper
Storage Technology, MD-3T, Louisville, CO 80028		303-673-5435