On Thu, 4 Mar 1999, Richard Rauch wrote:

> The form that I used was something like:
> 
>   groff -Tps -man <page>.<section> | lpr -Pps
> 
> ...where <page>.<section> is the filname of the man source file.  That
> works quite well if you do one at a time, but if you "bunch them up" in
> the printer queue, I seem to have problems.  If you haven't specifically
> done so, you might try the above with a couple of short man pages.

OK, I just did that, and it seems to work for me.

> refering to when I say that ``lpr -r'' does not seem to work.  The
> spooling is fine (other than my comments re. ``lprm''...).

Yes, it really doesn't work. Upon reconsideration, the work-around has
nothing to do with "-s". (Never mind!) The filter script I use takes
postscript on standard input, and emits the raw printer codes to
standard out. The key line looks like this:

/usr/pkg/bin/gs -q -sOutputFile=- "@stc.upp" /dev/stdin -c quit

So when I use your command, above (without the -Pps), there's no
temporary file for lpr to remove. In actual fact, ghostscript makes
files in /tmp, but those aren't known to lpr, and ghostscript removes
them itself. 

> > Never seen that either. While experimenting with pap last month, I had
> > occasion to use lprm many times, and it worked fine, on both the
> 
> Perhaps I am using it incorrectly.  Can you show me a concrete example of
> how to use it?  I tried what I thought was the obvious interpretation of
> the man page, and one or two less obvious interpretations.  None worked
> for me.

`lprm' with one job in the queue will remove that job. If there's two
or three say, `lpq' will list them, and then `lprm N', where N is a
small integer that matches the one given by lpq, will remove only that
job.

> > symlinks and the small files. (I'm running -current.) I do seem to
> > remember having problems making a printcap entry with any name except
> > "lp," so my only printer is named "lp." I comment out the Epson to use
> > pap, and vice-versa.
> 
> What is ``pap''?  Is pap the reason for not being able to have more than
> one printer?

No. "pap" is Apple's "Printer Access Protocol", used to print over the
network, to a Mac. Now that I think of it, there's no reason why I
couldn't have both a pap printer and a local printer (except that I
couldn't get lp to work with pap, and in my case, it's the same
printer, being physically moved from one machine to the other.)

> > > 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. 
> > 
> > As above?
> 
> I am not sure what you mean by ``As above?''  Are you refering to
> something that I said, or to something that you said?  I _do_ have two
> (active) printers listed in /etc/printcap; I do _not_ have ``pap'' (as far
> as I know); I do _not_ run -current.  lpr, lprm, lpc, lpq, groff, nroff,
> troff, and corresponding macro packages are all generic 1.3.3, as far as I
> know.

What I should have said was, you can have two _printers_, but you
can't have two _queues_ running on the same serial port. At one time,
it seemed like a good idea to me, too, but it just doesn't work. If
that's what you're doing, if "ps" and "lp" are the same printer,
there's just no way to keep the pages from getting mixed up! It's a
wonder all the jobs aren't completely garbled.

I suppose that you want to print plaintext some times, and postscript
at other times. The usual way is to install a filter that looks at the
magic in the beginning of the file, and pipes the input throught the
appropriate commands. OTH, my simple needs are met with the following
script:

case $1 in
    -c) cat /dev/stdin 
    ;;
     *) /usr/pkg/bin/gs -q -sOutputFile=- "@stc.upp" /dev/stdin -c quit
     ;;
esac

Per printcap(5), the `-c' is passed iff lpr is invoked as `lpr -l'.
That's only for playing with ghostscript. In all other cases, the job
is filtered through ghostscript transparently, just as if it were a
real postcript printer, except, of course, that real postscript
printers know how to print plaintext. I use "enscript" for plaintext.
Since "enscript" sends it's output to lpr by default, (as does dvips),
I don't find this system particularly limiting.