[net.bugs] lprm bug empties files

clp (04/20/83)

I'm afraid that it is worse than that....

I've always wondered why both the Bell and the Berkeley lpr systems were
 so bad. For example:

 (a) The lprm bug causes any file that was linked (for protection of files
     you don't want copied) by lpr to be zeroed; that's right, the ORIGINAL
     FILE WILL BE ZEROED. The only solution is to have lpr always copy the
     files to be printed so that lprm will "work". But, it's even worse:

 (b) Lprm is too stupid to realize that if more than one file was printed,
     you may want to remove only one of those files. When you give a file-
     name to be removed, it will zero the whole dfAXXXXX file as well! Too
     bad you didn't mean to remove them all... it doesn't even remove all
     the C files after it has done this, it only removes the first! Not
     only is it wrong, but it is wrong AND inconsistent about it.

A good lpr system in not that hard! I wonder why no one has done one?
 (I have heard of MDQS as a general queuer; does anyone have a good lpr
 system that sends signals or acts intelligently about partial removes?).

							    Charles L. Perkins
						    ...decvax!genrad!wjh12!clp

eby (04/21/83)

	A good lpr system in not that hard! I wonder why no one has done
	one?
					    Charles L. Perkins

Someone has.  The 'lp' subsystem in UNIX System III and V is quite a
bit better than 'lpr.'  In fact, 'lpr' is marked 'Obsolescent' in 5.0
manuals.  Although not bug-free, 'lp' handles removals correctly, and
provides other features such as easy addition/removal of printers from
the system, user-defined printer 'classes', status of print jobs,
customizable filters for different printers, provisions for hardwired
and dialup printers, etc.  It is also possible to customize the system
to do things such as:

	+ define printer destinations on remote machines
	+ define printer destinations which print at certain times of
	  day (e.g. late at night)
	+ define printer destinations for 'non-standard' printers.  For
	  example, we currently have an imagen as one of our destinations.
	  The filter takes care of handling the device-independent troff
	  input in the way this device expects.

The bad news: you probably have to get System III or V to use this.

					Robert Eby
					ucbvax!eagle!pegasus!eby

guy (04/21/83)

If you get System III, you get the same "lpr" you get with V7.  No "lprm",
either.  Sorry, you have to get System V in order to get the new spooler.
(We did a spooler that does the same things, with a superset of the V7/S3/4.1BSD
command language interface; it works nicely, but I don't know whether we're
selling it.  Of course, the CCI Power 5 series 68000 UNIX micros will have
it...)

						Guy Harris
						RLG Corporation
						{seismo,mcnc,we13}!rlgvax!guy

bob (04/22/83)

Concerning the buggy 4.1 lpr/lprm/lpq/... system:
	2.9bsd has new lpr software which is MUCH better than
	the 4.1bsd software.  It actually works!  It has a printcap
	file (like termcap) and can support multiple printers,
	multiple queues (large print jobs and small print jobs, etc.).
	The software looks like it (as like most stuff in 2.9) originated
	on a vax and I imagine that it will be in 4.2.
					-- bob
					   ucbvax!lbl-csam!lanl-a!unm-ivax!bob

mike (04/23/83)

Concerning the standard 'lpr's drawbacks:
   Some people have made better lp spoolers.
   Ours handles multiple printers (parallel and/or serial),
   multiple print queues (activate/deactive),	
   has a status inquiry ("lpc"), and in general
   works quite nicely, thank you, on:
   V7, SysIII(et.al), Berkeley, PDP, VAX.
Unfortunately, it's for sale (i.e. ain't free).
Contact a sales-type personna at Uniq Computer:
		312-879-1566
*Really* am sorry for the commercial crassness,
but the void has been filled.