On Friday 28 August 2009 00:40:41 Charles Wilson wrote:
> >> 1) replace the lpr script with the lpr.exe tool from cygutils
> >> Discussion? Pros/Cons? Opinions?
> > Earlier, I asked:
> > | Do we really need anything more sophisticated?
> > ...but I now see that you are proposing something less so.
> > Agreed, the printcap configuration syntax may be inconvenient
> > for your Mr. Average Win32 User, but the simplified tool you
> > advocate would be next to useless to me.
> Well, I wouldn't suggest that lpr (the script) GO anywhere. It'd
> still be available from sourceforge -- just not the default "lpr"
Sure, it would still be available, for those who know to look for it,
and who realise that your lpr.exe isn't as fully featured as the one
you've replaced; I guess I'm uncomfortable with the *replacement* of
a feature rich option with an *apparently* newer version, (greater
version number), which may actually be feature poor in comparison.
I am perfectly amenable to offering both as alternatives, say named
`lpr-basic' and `lpr-advanced', to reflect the differing levels of
BTW, on my MSYS box, I see:
$ which -a lp lpr
I don't know where that lpr.exe came from -- I certainly didn't
install it; I'm guessing it is part of the OEM support kit for our
PCL printers, but it doesn't offer the features I require from lpr,
hence I use the script, (/bin/lp and /bin/lpr are hard linked to the
same script; having grown up on SysV, I tend to use lp).
> Alternatively, the lpr.exe could be installed as
> '/bin/win32_lpr.exe' (and just packaged in cygutils-bin with
> "everything else"). lpr (the script) could be installed as
> '/bin/bsd_lpr' (sysv_lpr) and packaged as
> Then, there's no conflict. Install both, neither, just one,
> whatever. End users would need to copy one or the other of
> (win32_lpr.exe -> lpr.exe) or (bsd_lpr -> lpr) -- kindof a
> poor-man's "alternatives" system. (I'm trying to avoid suggesting
> anybody deliberately have both "lpr.exe" and "lpr" -- that way
> lies madness).
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).
> Maybe, much much much later, if mingw-get supports postinstall
> actions on a per-package basis (IMO it probably shouldn't, because
> such scripts would inevitably want to exploit MSYS tools and posix
> paths, but then that would conflict with mingw-get's ability to
> install only mingw tools with no MSYS pollution)
I did have post-install scripts in mind, as a future capability of
mingw-get, but I lean towards the idea of supporting them with a
simple embedded interpreter, rather than relying on an external
> ...but anyway, we
> might later add postinstall scripts to "automatically" copy
> [win32_lpr.exe|bsd_lpr] to [lpr.exe|lpr].
> Well, I was sure that YOU would definitely want the script version
> -- otherwise, why'd you scratch that itch? Since you published it
> in response to somebody ELSE asking for it -- on the cygwin list
> no less ...
No, it wasn't on the Cygwin list; it was a user running groff on
Cygwin, asking on the groff list.
> -- I can only assume that (a) lpr.exe didn't work for that
> person, and (b) I missed that email exchange. But it still seems
> to be a rare bird indeed that needs those features under MSYS or
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
$ 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, I wasn't suggesting that yours be withdrawn -- as in no
> longer accessible from sourceforge (nothing ever disappears from
No, but older packages, (or those with lower version numbers), tend
to be ignored by users; we should promote both as alternatives, for
differing audiences, in a manner which allows users to choose the
more appropriate for their needs. (Hence `lpr-basic' for those with
basic needs, `lpr-advanced' for those with more complex needs).
> Simply that as the non-default "lpr" for MSYS, it
> would take additional effort (download/unpack [or select as
> alternate in mingw-get], set up /usr/spool/lpr/.active, move
> lpr.exe out of the way) for users to exploit its capabilities.
Okay, provided it is apparent that this version is no less current
> And the default lpr for MSYS would be the one that just kinda
> works, but isn't very featureful.
> > $ od -Ax -tx2z mingw-get.exe | head
> Cool. I never can figure out how to get what I want from od.
> That's going into the bash.alias file right now. Thanks.
You're welcome. FWIW, I knew I could get that format, but I had to
refer to the manpage, to remind myself how to do it.
> > [mkshortcut] Could be useful for installers; even more so if its
> > capabilities can be provided as library functions, for *native*
> > use in mingw-get.
> Meh. 705 physical source lines - mostly argument handling stuff.
> The meat of the tool is maybe 100 lines or so (and some of THAT is
> cygwin_conv_to_win32_path stuff). I'd just grab the guts and
> import it into mingw-get directly. It's GPL.
Okay. I'll take a look, (although it will likely have to wait until
I get to maybe adding an embedded post-install script interpreter).
I was planning to GPL mingw-get anyway.
> >> I tend to feel that any variation of #2 is dependent on a
> >> positive answer to #1, but maybe not.
> > The two don't really seem to be interdependent, IMO.
> Well, no...but they're interdependent on my effort. Marginal
> utility for the extras + significant ease-of-use improvement for
> lpr == go ahead and port cygutils. Remove one component or the
> other, and the bang-for-my-effort is less. That's all.
Ah ha! So it's more a case of you thinking the porting effort isn't
worthwhile, if lpr.exe isn't the primary objective. Fair comment.