> >   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
> <http://www.netbsd.org/Misc/send-pr.html>.

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
database.


> > > > > > 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,
   this weekend.

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." --rauch@eecs.ukans.edu