Re: [MinGW-dvlpr] RFC: lpr

On Saturday 29 August 2009 00:32:06 Charles Wilson wrote:
> > Madness indeed. I quite like the idea of different distribution
> > names though, allowing the user to choose which to promote as
> > his actual lpr; (of course, `lp' for the script, and lpr.exe
> > would work just as well).
>
> IIRC, your script is *documented* to behave differently if invoked
> via 'lp' vs. 'lpr' -- one way recognizes the sys-v option set, the
> other way recognizes the bsd option set. However, the
> *implementation* doesn't work like that; instead, it always
> recognizes the superset of both option sets.
Uhmm, no:
# we can now parse the "lp" command line options ...
# ( this may override the default "$LPDEST" ) ...
#
if test "${CMD:=$(basename $0)}" = "lpr"
then
#
# when invoked as "lpr" ...
# then we must honour the BSD option set ...
#
while getopts 1:2:3:4:"#":cC:dfghi:J:lmnpP:rstT:U:vw: opt
do
.
.
done
#
else
#
# when invoked as "lp" ...
# then we honour the UNIX System V "lp" option set ...
#
while getopts cd:f:H:imn:o:pP:q:rsS:t:T:wy: opt
do
.
.
done
fi
> As it is, then simply running it in-place as "bsd_lpr" would work
> fine. OTOH, if the implementation is "fixed" to match the
> documentation, then the end-user *must* copy it to lpr|lp before
> using.
Again, I think not; I appear not to have insisted on it being either
lpr or lp, but if it isn't *exactly* "lpr", then "lp" is assumed,
and the SysV option set will apply, (which might seem odd for a
filter proclaiming to be "bsd_lpr").
> Ah: found it.
> http://www.mail-archive.com/groff@.../msg03622.html
>
> > IIRC, the scenario ran something like this: maybe
> >
> > $ groff -Tlj4 -ms foo.ms | lpr.exe
> >
> > on a PCL spool produces acceptable output, but add pictures or
> > diagrams to the document stream, and grolj4 doesn't handle them
> > well, so
> >
> > $ groff -p -Tlj4 -ms foo.ms | lpr.exe
> >
> > isn't acceptable, whereas
> >
> > $ groff -p -Tps -ms foo.ms | lpr -g
> >
> > (with -g selecting a GhostScript ps --> PCL filter within
> > printcap) achieves good quality output on that same PCL printer.
>
> Well...THAT wasn't in the thread I found!
Maybe not. My memory is hazy; neverless, the scenario is real: my
recollection may have come from the experiences of my own project
group, rather than from public record.
> Anyway, there's no doubt
> that your lpr script is much more capable that cygutils' lpr.exe,
> and I'm sure it's quite useful -- when you need those
> capabilities. But for poor schmoes like me...simple is gooood.
Sure. When I wrote that, last week, I was away from the office, and
again my hazy memory let me down; in reality, I have the GhostScript
filter attached to a distinct printcap entry, rather than selected
by the -g option:
LPT2 is configured (as default printer) for PCL-5
LPT2-ps is the same printer, emulating Postscript via a gs filter
so:
groff -Tlj4 -ms foo.ms | lpr
is fine for text-only documents, but
groff -p -Tps -ms foo.ms | lpr -P LPT2-ps
is *much* better, when the document includes pictures or diagrams.
> But messing around with names, (e.g. "bsd_lpr -> lpr_advanced",
> "lpr.exe -> lpr_basic.exe") is fine, so long as -- until our
> installer is capable of postinstall scripts -- one or the other is
> also installed as the main "lpr[.exe]". For ease of use, I'd
> prefer that be the cygutils version.
Agreed on the choice of the cygutils version, for simplicity, as the
default. Given that my lpr package, (in spite of its apparent BSD
heritage in printcap), actually offers a hybrid subset of both SysV
and BSD functionality, (and by default is SysV), I think I'd prefer
a package name such as lpr-advanced, or lpr-enhanced; (I hesitate to
suggest lprng).
--
Regards,
Keith.