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.