Subject: Re: Printing.
To: Frederick Bruckman <email@example.com>
From: Richard Rauch <firstname.lastname@example.org>
Date: 03/05/1999 10:14:50
> > Is it a deliberate feature to not support ``-r'', or is it a bug?
> > (If the former, then the man page should be updated...)
> > I wouldn't have guessed that it would be deliberate, save that the
> > GNU/LINUX lpr man page seems to have a low opinion of supporting ``-r'';
> > so, I wondered if perhaps they had a good reason for their attitude, and
> > our own lpr might have been modified by someone of a like mind?
> Well, I don't care to speculate on what's "deliberate." (Deliberate by
> who? Everyone? Anyone who wants to could supply a patch, or file a
Deliberate by whoever made the change. (I am tacitly assuming that, once
upon a time, the BSD lpr worked as the man page claims, and therefore it
has been broken---either deliberately or accidentally---since that time.)
If someone with the authority to make such a change said one day, ``You
know, `-r' on lpr is pure brain-damage. I will simply disable it,'' then
there would be little point in my bug-rep'ing it, would there? (Possibly
the man-page would deserve a bug-rep to be brought into line, but
bug-rep'ing the program probably wouldn't do any good.)
Apparently, however, no one reading this list knows why it might have been
disabled, so I can assume that lpr itself has a bug. I'll go grab my
computer's uname output and file a bug report later today or tomorrow.
> pr.) I could be wrong, but I seem to remember seeing something about
> this in the bug database. I'm not that all interested in this one, but
> you might care to search the database for yourself at
I already did, yesterday or today. I didn't turn up anything, or else I
missed it somehow. That doesn't say whether it was a deliberate change,
however; it just tells me that there is no bug report in the database.
Silence on the mail-list is much more informative than a void in the bug
> > > > > > As far as I can tell, lprm doesn't do what it is supposed to do. The
> > > > > > oddity of my system is that the ``ps'' and ``lp'' printers both directly
> > > > > > drive the same printer harder (``ps'' doesn't pass it off through ``lp'';
> > > > > > perhaps a mistake, but it shouldn't affect the queues, should it?). The
> > > > > > two printers have seperate /var/spool/output queue directories.
> No, I'm sorry. I don't see any benefit to having two spools for one
> printer. What does that do for you that one spool can't do, assuming
> you can get it to work at all?
A) It does work quite well, in general. I agree that with the very
naive handling that I have currently, it could easily have problems
if I sent print jobs to both logical printers simultaneously. I
do not believe that the problem is inherant in having two queues,
only in having two queues poorly managed. I'll play around and learn,
B) I find it simpler, conceptually, to send my postscript files to
a ``PostScript printer'', than to use the ``literal control codes''
to get straight ASCII on my ``line printer''. (Or, conversely, to use
``literal control codes'' to get PostScript conversion...)
I may be biased, here, because that's how all of the HP laser printers
are handled around campus. There is, for example, a `236' (Snow 236)
laser printer that does PostScript, and a `236t' which is the same
physical printer---but it handles straight ASCII. I find it quite
natural to use that way.
That they've been doing it this way for at least a couple of years
(with no hitches that I'm aware of) is a good argument that it works
quite well in practice (on a multiuser network), if properly set up.
C) I can extend this concept by adding new logical printers (say,
one that automatically knows EBCDIC, if for some reason I needed
such a translation). The printer name-space is much wider and
more flexible than the printer command-line switch-space.
(Although, as Brook Milligan points out, I could break down and
use magicfilter; my primary resistance to that suggestion is that
if I did that, I wouldn't learn anything at all.)
D) I quite understand that you may not agree. Happily, you do not have
to use the box in my apartment, nor do I have to use your box, so if
we have different approaches, there is no harm done. I'm not
advocating that you switch.
"I probably don't know what I'm talking about." --email@example.com