RFC: lpr

[Charles Wilson-8]

About a 18 months ago, Keith uploaded an "lpr" package for msys which
consisted of a shell script and configuration support, which mimics the
behavior of the lpr system available on unix, but without the need for
an lpd daemon (other than the spooler built in to Windows). It supports
pre-printing filters, and all of the options that the BSD lpr tool does
(although it doesn't actually /implement/ all of those behaviors).

It appears that Keith's version is focused mostly on more-or-less
seamless replacement of BSD lpr in non-interactive (scripted) uses,
where "must support all the same options even if ignored" is important.
It requires manual configuration of the /usr/spool/lp/config/.active
file (usually hardlinked to /etc/printcap) -- just like on unix.  This
provides familiarity for unix admins and additional flexibility, but
this power comes at a cost of extra unfamiliar effort for your typical
win32 user.

For instance, you can create two printcap entries for the same printer,
where one is "normal" but the other automatically prints as galley
proofs with a 'DRAFT' watermark.  With filter and printcap support, this
is "easy".  With non-msys win32 you can do it only (a) if your printer
driver supports such things, and (b) you configure that setup manually
for each job using the win32 printer setup gui.  With lpr.exe (below),
you just /can't/ do this at all -- but you don't need to set up an
/etc/printcap file using Yet Another Configuration Language, either.

Anyway, the lpr script works by basically creating a raw data file for
the printer and inserting various control characters (line width, page
feed, etc) as specified by /etc/printcap for that printer.  Then, it
cats the input file thru the appropriate filter (again, as specified by
/etc/printcap for that printer definition) and pipes it to the printer
directly:

  eval /bin/cat $LP_SPOOL_FILE ${LP_DRIVER:+"| $LP_DRIVER"} > $LP_STREAM

where LP_STREAM may be something like "//printserver/PRINTER2".


OTOH, cygwin and GNUWin32 have long provided an lpr.exe utility (man
page below), which also doesn't require a separate daemon (other than
the spooler built in to Windows).  This lpr.exe uses Win32 API calls to
directly insert the document into the spooler's queue.  While it
supports many of the same options as BSD lpr, it makes no claim of
complete compatibility.

The goal of cygwin's lpr.exe is to support manual (or mostly manual,
e.g. enscript) printing of documents. Since no formatting or filtering
is done, it is useful for "raw" documents only such as .prn files, or
.ps files (if your printer is postscript). It may or may not work with
plain .txt files -- see below.

The lpr script supports both the $PRINTER and $LPDEST variables; lpr.exe
supports only the $PRINTER variable -- although both support the -d and
-P switches to specify explicitly the printer.  lpr.exe can also use the
Win32 "Default Printer" if those variables are not set and -P/-d is not
specified.

lpr.exe supports win32 UNC notation as well as the win32 "printer name"
-- for instance, the default cygwin /etc/profile contains this snippet:

PRINTER=""
case `uname -s` in
CYGWIN_NT-*)
        PRINTER="`regtool -q get '\user\Software\Microsoft\Windows
NT\CurrentVersion\Windows\Device' | sed 's/,.*$//'`"
        ;;
CYGWIN_9?-*)
        PRINTER="`regtool -q get
'\config\System\CurrentControlSet\Control\Print\Printers\Default'`"
        ;;
esac
export PRINTER

which, on my Vista system, results in
   PRINTER="Brother HL-5250DN (direct)"
and that works just fine.

(we can't do this automatically on msys because we don't have regtool;
it is present in winsup back to 2000, but is not part of our fork even
though MSYS was forked in 2001)


I am unsure whether, for non-PS printers, that EITHER of these two lpr
implementations allow you to do
   lpr foo.txt
since all of my printers are PS.  'lpr.exe foo.txt' works fine with *MY*
printer, but I'm not sure if that is because it is PS, or just a
peculiarity with the 'Brother HL-5250DN' model, or because it Just
Works(tm) everywhere.  I dunno.



lpr.exe is part of the cygutils package, which also provides several
other useful utilities, including a different implementation of
dos2unix/unix2dos/u2d/d2u, the 'dump' hexdumper, the 'mkshortcut' and
'readshortcut' tools, and the 'putclip' and 'getclip' tools.  cygutils
also contains some IPC utilties, a 'realpath' tool [passthru to
realpath(3)], cygstart, and a few others.


So, with regards to lpr, I have two more-or-less separate proposals:

1) replace the lpr script with the lpr.exe tool from cygutils

   Discussion? Pros/Cons? Opinions?

   One thing: nobody on cygwin has ever, to my knowledge, complained
   that cygwin's lpr.exe can't do all the nifty filtering and
   preprocessing that regular unix lpr's can.  So I'm not sure anyone
   will miss the lpr script's partial implementation of these things
   on MSYS.


2) also provide *some* but not all of the other utilities from cygutils.

      u2d/d2u: this impacts the "msysCORE" component, which currently
               provides a script implementation (delegates to [g]awk)

      unix2dos/dos2unix: impacts mingw-utils, which as of 0.3 provides
               exes for these two tools.

        PRO: Same tool for all 4 names, rather than multiple
             different implementations. Commonality with cygwin (let
             them find/fix bugs).  Somewhat safer; without --force
             the cygutils version will detect binary files and avoid
             "converting" them.

      dump: very simple. Like 'od -t x2' but also prints ASCII repr

/usr/bin/id.exe:
00000000  4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ..............
00000010  b800 0000 0000 0000 4000 0000 0000 0000 8.......@.......
00000020  0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030  0000 0000 0000 0000 0000 0000 8000 0000 ................
00000040  0e1f ba0e 00b4 09cd 21b8 014c cd21 5468 ..:..4.M!8.LM!Th
00000050  6973 2070 726f 6772 616d 2063 616e 6e6f is program canno
00000060  7420 6265 2072 756e 2069 6e20 444f 5320 t be run in DOS
00000070  6d6f 6465 2e0d 0d0a 2400 0000 0000 0000 mode....$.......
...

      mkshortcut: creates win32-style shortcuts; allows to specify
                  name, target and arguments, startin, icon, tooltip,
                  etc. Also allows to create automatically in AllUsers
                  or current user's start menu or desktop.

      readshortcut: read data from a windows shortcut (.lnk) file

      putclip: copy stdin to windows clipboard
      getclip: copy windows clipboard to stdout


(NOTE: obviously the IPC utilities are useless for MSYS. Ditto realpath
IMO, since we have no symlink support, and realpath(3) doesn't
"canonicalize" hardlinks nor mountpoints.  So the only useful thing it
would do on MSYS is collapse a/b/../c to a/c.  cygstart is definitely
useless, since msys dll + the start "script" will DTRT).

I tend to feel that any variation of #2 is dependent on a positive
answer to #1, but maybe not.

Comments?

--
Chuck


NAME
       lpr - Spool files to a printer

SYNOPSIS
       lpr [-D] [-d device ] [-h] [-l] [-P device ]

DESCRIPTION
       lpr  spools a file to the specified printer device.
       No formatting is done -- data is sent  "raw".  This
       is useful, for example, for sending Postscript data
       to a Postscript printer.

OPTIONS
       -D     enables some debugging output.

       -d device
              specifies the device to which  to  send  the
              output.

       -h     does nothing and is accepted for compatibil-
              ity only.

       -l     disables CR/LF translation. Normally,  files
              are converted to DOS/Windows-style line end-
              ings (CR+LF) during  the  spooling  process.
              Some drivers appear to require this transla-
              tion, while most don't seem to care. Includ-
              ing this option on the lpr command line dis-
              ables any such translations.

       -P device
              an alias for -d.

DEVICES
       A   device    name    may    be    a    UNC    path
       (\\server_name\printer_name), a reserved DOS device
       name (e.g., prn, lpt1), or a local port  name  that
       is  mapped  to  a  printer share. Note that forward
       slashes may be used  in  a  UNC  path  also  (e.g.,
       //server_name/printer_name).

[[[ ed: as stated above, the "win32 name" also works,
    e.g. "Brother HL-5250DN (direct)" ]]]

ENVIRONMENT
       A  default  device  name  may  be  specified in the
       PRINTER environment variable. Specifying  a  device
       via  a -d or -P will override the environment vari-
       able setting.

NOTES
       Make sure that the default paper  size  setting  is
       correct  for  the  program  that  is formatting the
       page. For example,  for  enscript,  make  sure  the
       DefaultMedia      setting     is     correct     in
       /etc/enscript.cfg. If this setting is incorrect, it
       is  possible that no output at all will be produced
       by the printer. This is not an lpr issue.

AUTHORS
       Written by Rick Rankin.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Thursday 27 August 2009 19:54:05 Charles Wilson wrote:
> About a 18 months ago, Keith uploaded an "lpr" package for msys

I actually wrote it around 1999/2000, but didn't publish it until a
groff user (on Cygwin) asked for a method of achieving what it does.

> which consisted of a shell script and configuration support, which
> mimics the behavior of the lpr system available on unix, but
> without the need for an lpd daemon (other than the spooler built
> in to Windows). It supports pre-printing filters, and all of the
> options that the BSD lpr tool does (although it doesn't actually
> /implement/ all of those behaviors).
>
> It appears that Keith's version is focused mostly on more-or-less
> seamless replacement of BSD lpr in non-interactive (scripted)
> uses, where "must support all the same options even if ignored" is
> important.

It was initially modelled on LPD/LPR on Red Hat 6 *and* lpsched/lp on
SysV (Solaris), so that our users of either of those systems could
use familiar commands from Cygwin.  It wasn't so much that support
for all of the lp or lpr options was important, as that I listed
them all, with the intention of maybe implementing them later, if
they were found to be useful, and easily emulated.

> It requires manual configuration of the
> /usr/spool/lp/config/.active file (usually hardlinked to
> /etc/printcap) -- just like on unix.  This provides familiarity
> for unix admins and additional flexibility, but this power comes
> at a cost of extra unfamiliar effort for your typical win32 user.
>
> For instance, you can create two printcap entries for the same
> printer, where one is "normal" but the other automatically prints
> as galley proofs with a 'DRAFT' watermark.  With filter and
> printcap support, this is "easy".

It is also imperative, for the use I make of lpr, on my MSYS box:
| I based it's configuration on an LPD/LPR model, because that was
| convenient for letting me push plain text files, or groff's
| PostScript output to a single physical HP PCL-5 printer, while
| allowing that one device to simulate several logical printers, with
| a variety of character pitches and page orientations, without me
| having to jump through hoops every time I wanted a different
| layout.

> With non-msys win32 you can do
> it only (a) if your printer driver supports such things, and (b)
> you configure that setup manually for each job using the win32
> printer setup gui.  With lpr.exe (below), you just /can't/ do this
> at all -- but you don't need to set up an /etc/printcap file using
> Yet Another Configuration Language, either.

> So, with regards to lpr, I have two more-or-less separate
> proposals:
>
> 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.

>    One thing: nobody on cygwin has ever, to my knowledge,
> complained that cygwin's lpr.exe can't do all the nifty filtering
> and preprocessing that regular unix lpr's can.  So I'm not sure
> anyone will miss the lpr script's partial implementation of these
> things on MSYS.

See my comment above; I definitely would miss that.  Of course I can
always continue to use my script, but why should other users not be
offered the same choice?  If we withdraw my script, in favour of the
simpler lpr.exe, we make it more difficult for those who do want the
more advanced features.

> 2) also provide *some* but not all of the other utilities from
> cygutils.
>
>     u2d/d2u: this impacts the "msysCORE" component, which
> currently provides a script implementation (delegates to [g]awk)
>
>     unix2dos/dos2unix: impacts mingw-utils, which as of 0.3
> provides exes for these two tools.
>
>         PRO: Same tool for all 4 names, rather than multiple
>              different implementations. Commonality with cygwin
> (let them find/fix bugs).  Somewhat safer; without --force the
> cygutils version will detect binary files and avoid "converting"
> them.

Maybe.  Cesar and I did discuss this, at the time we added u2d and
d2u.  Provided we have a u2d/d2u pair that operate as pure filters,
I don't really have a strong opinion on how these are furnished.

>     dump: very simple. Like 'od -t x2' but also prints ASCII repr

Why do we need dump?  I can get (almost) identical output to this:

> /usr/bin/id.exe:
> 00000000  4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ..............
> 00000010  b800 0000 0000 0000 4000 0000 0000 0000 8.......@.......
> 00000020  0000 0000 0000 0000 0000 0000 0000 0000 ................
> 00000030  0000 0000 0000 0000 0000 0000 8000 0000 ................
> 00000040  0e1f ba0e 00b4 09cd 21b8 014c cd21 5468 ..:..4.M!8.LM!Th
> 00000050  6973 2070 726f 6772 616d 2063 616e 6e6f is program canno
> 00000060  7420 6265 2072 756e 2069 6e20 444f 5320 t be run in DOS
> 00000070  6d6f 6465 2e0d 0d0a 2400 0000 0000 0000 mode....$.......

...just by using od:

  $ od -Ax -tx2z mingw-get.exe | head
  000000 5a4d 0090 0003 0000 0004 0000 ffff 0000  >MZ..............<
  000010 00b8 0000 0000 0000 0040 0000 0000 0000  >........@.......<
  000020 0000 0000 0000 0000 0000 0000 0000 0000  >................<
  000030 0000 0000 0000 0000 0000 0000 0080 0000  >................<
  000040 1f0e 0eba b400 cd09 b821 4c01 21cd 6854  >........!..L.!Th<
  000050 7369 7020 6f72 7267 6d61 6320 6e61 6f6e  >is program canno<
  000060 2074 6562 7220 6e75 6920 206e 4f44 2053  >t be run in DOS <
  000070 6f6d 6564 0d2e 0a0d 0024 0000 0000 0000  >mode....$.......<
  000080 4550 0000 014c 0007 f61e 4a8f 0000 0000  >PE..L......J....<
  000090 0000 0000 00e0 030e 010b 3802 5200 0000  >...........8.R..<

>     mkshortcut: creates win32-style shortcuts; allows to specify
>                 name, target and arguments, startin, icon,
> tooltip, etc. Also allows to create automatically in AllUsers or
> current user's start menu or desktop.

Could be useful for installers; even more so if its capabilities can
be provided as library functions, for *native* use in mingw-get.

>     readshortcut: read data from a windows shortcut (.lnk) file

Maybe less useful, but I guess if we provide mkshortcut, it makes
sense to provide its complement too.

>     putclip: copy stdin to windows clipboard
>     getclip: copy windows clipboard to stdout

putclip would certainly be more convenient that highlight and copy;
getclip is easily emulated with:

  $ cat <<EOF
  <Shift-Insert>
  EOF

...but again, as a natural complement to putclip, it makes sense.

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

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:

>> So, with regards to lpr, I have two more-or-less separate
>> proposals:
>>
>> 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" tool.

To support providing both, I'd package lpr.exe in
  lpr-1.3.4-1-msys-1.0.11-bin  (whose -src is cygutils)
All the other stuff would go in
  cygutils-1.3.4-1-msys-1.0.11-bin

Then, anyone could choose to install "my" lpr or "your" lpr:
  lpr-1.0.1-1-MSYS-src.tar.gz
(probably needs to be repackaged. or something. packages full of only
scripts don't fit our package naming schema very well. I dunno).

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
  bsd_lpr-1.0.2-1-msys-1.0.11-[bin/src/???]

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

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)...but anyway, we might later add postinstall
scripts to "automatically" copy [win32_lpr.exe|bsd_lpr] to [lpr.exe|lpr].

Or not.

>>    One thing: nobody on cygwin has ever, to my knowledge,
>> complained that cygwin's lpr.exe can't do all the nifty filtering
>> and preprocessing that regular unix lpr's can.  So I'm not sure
>> anyone will miss the lpr script's partial implementation of these
>> things on MSYS.
>
> See my comment above; I definitely would miss that.

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

> Of course I can
> always continue to use my script, but why should other users not be
> offered the same choice?  If we withdraw my script, in favour of the
> simpler lpr.exe, we make it more difficult for those who do want the
> more advanced features.

Well, I wasn't suggesting that yours be withdrawn -- as in no longer
accessible from sourceforge (nothing ever disappears from sourceforge).
 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.

And the default lpr for MSYS would be the one that just kinda works, but
isn't very featureful.

>> 2) also provide *some* but not all of the other utilities from
>> cygutils.
>>
>>     u2d/d2u: this impacts the "msysCORE" component, which
>> currently provides a script implementation (delegates to [g]awk)
>>
>>     unix2dos/dos2unix: impacts mingw-utils, which as of 0.3
>> provides exes for these two tools.
>>
>>         PRO: Same tool for all 4 names, rather than multiple
>>              different implementations. Commonality with cygwin
>> (let them find/fix bugs).  Somewhat safer; without --force the
>> cygutils version will detect binary files and avoid "converting"
>> them.
>
> Maybe.  Cesar and I did discuss this, at the time we added u2d and
> d2u.  Provided we have a u2d/d2u pair that operate as pure filters,
> I don't really have a strong opinion on how these are furnished.

The cygutils versions can operate as pure filters.

>>     dump: very simple. Like 'od -t x2' but also prints ASCII repr
>
> Why do we need dump?  I can get (almost) identical output
> ...just by using od:
>
>   $ 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.

>
>>     mkshortcut: creates win32-style shortcuts; allows to specify
>>                 name, target and arguments, startin, icon,
>> tooltip, etc. Also allows to create automatically in AllUsers or
>> current user's start menu or desktop.
>
> 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.

>>     readshortcut: read data from a windows shortcut (.lnk) file
>
> Maybe less useful, but I guess if we provide mkshortcut, it makes
> sense to provide its complement too.

Yeah, that was my feeling.  mkshortcut is nice (I've used it when
putting together a custom MSYS package for my team at work) but
readshortcut is mostly just for symmetry.

>>     putclip: copy stdin to windows clipboard
>>     getclip: copy windows clipboard to stdout
>
> putclip would certainly be more convenient that highlight and copy;
> getclip is easily emulated with:
>
>   $ cat <<EOF
>   <Shift-Insert>
>   EOF
>
> ...but again, as a natural complement to putclip, it makes sense.

Ah...but <Shift-Insert> doesn't work in rxvt (although middle-click
does).  I agree -- I routinely use putclip on cygwin (even though cygwin
also supports /dev/clipboard, but MSYS doesn't). I hardly ever use
getclip mostly because Shift-Insert/middle-click actually work in vi --
kinda hard to shell-out to getclip and capture its stdout into your
opened doc.  But again, symmetry.

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

--
Chuck

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

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"
> tool.

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
features supported.

BTW, on my MSYS box, I see:

  $ which -a lp lpr
  /bin/lp
  /bin/lpr
  /c/WINNT/system32/lpr.exe

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
> bsd_lpr-1.0.2-1-msys-1.0.11-[bin/src/???]
>
> 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
scripting host.

> ...but anyway, we
> might later add postinstall scripts to "automatically" copy
> [win32_lpr.exe|bsd_lpr] to [lpr.exe|lpr].

We might.

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

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, I wasn't suggesting that yours be withdrawn -- as in no
> longer accessible from sourceforge (nothing ever disappears from
> sourceforge).

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

> And the default lpr for MSYS would be the one that just kinda
> works, but isn't very featureful.

...this one.

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

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:
> 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
> features supported.

Fair enough. I've sent you a PM with some tentative packages and such
(crossed in the interwebs).

> BTW, on my MSYS box, I see:
>
>   $ which -a lp lpr
>   /bin/lp
>   /bin/lpr
>   /c/WINNT/system32/lpr.exe
>
> I don't know where that lpr.exe came from

It's actually part of windows -- but although it has the same name and
serves a similar purpose to the familiar tools on unix, it's Just
Different Enough to be annoying.  That's why cygutils has its own
version, which while limited in capabilities compared to the unix
versions, is more unix-like.

>> 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
>> bsd_lpr-1.0.2-1-msys-1.0.11-[bin/src/???]
> 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.

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.

I'm not sure any of the preceeding is worth worrying about, but I wanted
to make a note of it.

Anyway, in the PM I sent, you'll see I proposed installing "your"
version as /bin/bsd_lpr (and even repackaged the source as "bsd_lpr"),
while cygutils-bin contains "lpr.exe".  IMO, this actually gives the
bsd_lpr *more* visibility than the cygutils version, except that I believe

  1) cygutils-bin, since it contains u2d.exe/d2u.exe which "replace"
     the u2d/d2u scripts currently part of msysCORE, would eventually
     become part of the msys-BASE "profile"

  2) this means that cygutils-bin's "lpr.exe" would be available by
     default.  So, only those whose needs aren't satifies by the
     capabilities of lpr.exe (documented [*] as more limited than the
     bsd_lpr version) would go looking for the visible add-on "bsd_lpr"
     package.

I think, for now, this is a reasonable approach, until we actually have
postinstall scripting support in the installer.  However, I'm perfectly
willing to do whatever renaming you'd like, in either bsd_lpr or
cygutils, or splitting the cygutils-bin package to provide
lpr[_basic].exe separately.  Whatever.

> 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
> scripting host.

Ah.  That makes sense.  Difficult, but sensible.

> No, it wasn't on the Cygwin list; it was a user running groff on
> Cygwin, asking on the groff list.

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

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

Hmmm. Well, I *think* the proposal above satisfies the main concern:
bsd_lpr (or whatever you want me to call it) would stand as a "top
level" package:

  MSYS bsd_lpr
     bsd_lpr-1.0.2-1
        <files>

while the default lpr, cygutils' lpr.exe, would simply be buried in

  MSYS cygutils
     cygutils-1.3.4-1
        cygutils-1.3.4-1-msys-1.0.11-bin.tar.lzma

(without even its own "lpr-1.3.4-1-msys-1.0.11-bin.tar.lzma" subpackage,
although splitting into an
"lpr[_basic?]-1.3.4-1-msys-1.0.11-bin.tar.lzma" is certainly doable. As
I said above, I believe cygutils-bin will eventually find its way into
msys-BASE, so...at that point, if lpr[_basic?]-bin is "buried" under
cygutils, then lpr_basic becomes effectively invisible unless it too is
added to the msys-BASE profile. In which case, why would it be split out
from cygutils-bin?

Anyway, I'd make sure that the cygutils.RELEASE_NOTES adequately
document [*] the limitations of the cygutils lpr.exe, and refer to the
bsd_lpr package for those that want "something better".

[*] it doesn't do this yet, but it will, before I upload any of these
packages to the FRS.  If you think it worthwhile, I could even patch the
MSYS version of lpr.exe's --help output and man page to mention bsd_lpr
(lpr_advanced, etc) package...


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.

>> 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
> than...
>
>> And the default lpr for MSYS would be the one that just kinda
>> works, but isn't very featureful.
>
> ...this one.

Ack.

[snip disc. of mkshortcut code]
> 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).

Right.

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

Yep, you got me (esp. when it also involved porting popt, given the
rpm.org-vs-rpm5.org fork insanity).

--
Chuck


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

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.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:
> On Saturday 29 August 2009 00:32:06 Charles Wilson wrote:
>> 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:

[snip evidence that I really need a new eyesight prescription]
I really don't know how I missed that. I /did/ look, but only briefly
and it was pretty late...

>> 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").

Yeah, it would be odd.  Let's solve it however you like: change the
default to go with the bsd option set; change the package name and
default installation name to sysv_lpr; or change the package name and
default inst name to something else, like lpr_advanced?

Ah, I see below you prefer lpr-advanced/enhanced. Fine with me.

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

Sure.

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

Err, yeah...the possibility for confusion with the Pseudo Random Number
Generator daemon/tool is pretty high, I would think.

Are hyphens ok with our pkg naming scheme? Checking...

$ pkginfo.exe lpr-advanced-1.0.3-1-msys-1.0.11-bin.tar.bz2
Package Name:      lpr-advanced
Package Version:   1.0.3
Package Build:     1
Subsystem Name:    msys
Subsystem Version: 1.0.11
Subsystem Build:   <unspecified>
Release Status:    <unspecified>
Release Reference: <unspecified>
Component Type:    bin
Component Version: <unspecified>
Archive Format:    tar
Compression Type   bz2

Yep.

Assuming you're ok with the basic *idea* of repackaging your original
lpr in this way, can you toss me a Makefile.in that DTRT, without
automake (per our private conversation)?  I can take it from there...

Also, unless I hear an objection, I'll also modify cygutils-*-bin to
install its version as both lpr-basic.exe and lpr.exe, at least for now.
Any comments on patching lpr.exe docu/--help to "advertise" lpr-advanced?

--
Chuck


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Thursday 03 September 2009 22:35:56 Charles Wilson wrote:
> > 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).
>
> Err, yeah...the possibility for confusion with the Pseudo Random
> Number Generator daemon/tool is pretty high, I would think.

Well, I was actually thinking of potential for confusion with the
`lpr next generation' package (www.lprng.com), which made a brief
appearance on some GNU/Linux distributions, before CUPS became the  
more-or-less standard spooler implementation; some bright spark is
sure to assume that our "lprng" would be a port of that, which, in
spite of its similarity of purpose, it certainly would not be.

> Assuming you're ok with the basic *idea* of repackaging your
> original lpr in this way, can you toss me a Makefile.in that DTRT,
> without automake (per our private conversation)?  I can take it
> from there...

Yeah, I'm okay with the idea.  I've done a bit more than just create
a Makefile.in, so I'll set up the initial CVS infrastructure, and we
can take it from there.  FWIW, I've chosen to adopt `lpr-enhanced'
as the package name.

> Also, unless I hear an objection, I'll also modify cygutils-*-bin
> to install its version as both lpr-basic.exe and lpr.exe, at least
> for now.

Okay.  The `install' rule in my Makefile.in, as it currently stands,
checks for an existing `${bindir}/lpr.exe', and moves it out of the
way, (by making this a prerequisite of `install'):

  # If the user has cygutils' `lpr.exe' installed,
  # we move it out of the way.
  #
  install-lpr-basic:
          if test -e ${bindir}/lpr.exe; then \
            rm -f ${bindir}/lpr-basic.exe; \
            mv ${bindir}/lpr.exe ${bindir}/lpr-basic.exe; \
          fi

> Any comments on patching lpr.exe docu/--help to "advertise"
> lpr-advanced?

I'm happy to leave that to your discretion.

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:
> On Thursday 03 September 2009 22:35:56 Charles Wilson wrote:
>> Err, yeah...the possibility for confusion with the Pseudo Random
>> Number Generator daemon/tool is pretty high, I would think.
>
> Well, I was actually thinking of potential for confusion with the
> `lpr next generation' package (www.lprng.com)... some bright spark is
> sure to assume that our "lprng" would be a port of that, which, in
> spite of its similarity of purpose, it certainly would not be.

Ah, I see. I had never heard of that package before.  Anyway, I like
lpr-enhanced/advanced better anyway.

> Yeah, I'm okay with the idea.  I've done a bit more than just create
> a Makefile.in, so I'll set up the initial CVS infrastructure, and we
> can take it from there.  FWIW, I've chosen to adopt `lpr-enhanced'
> as the package name.

Oh, okay. Thanks for doing that. I see that about 8hours after you sent
this email, that you created the initial CVS infrastructure with the
(unchanged) files from the original lpr-1.0.1-msys package.  However,
the additional build infrastructure that you've (privately) developed
and mention below is not yet there (no rush), so I'll wait before
commenting further.

>> Also, unless I hear an objection, I'll also modify cygutils-*-bin
>> to install its version as both lpr-basic.exe and lpr.exe, at least
>> for now.
>
> Okay.  

Great. I'll get started on that. (Also, I'll take that as approval to go
ahead with the cygutils package as previously proposed and with the
contents described). Repeating:

  bin/conv.exe
  bin/d2u.exe
  bin/dos2unix.exe
  bin/getclip.exe
  bin/lpr.exe
  bin/lpr-basic.exe
  bin/mkshortcut.exe
  bin/putclip.exe
  bin/readshortcut.exe
  bin/u2d.exe
  bin/unix2dos.exe

This obviously will "conflict" with mingw-utils-0.3 as it is currently
composed. I'll start a new thread with some proposals there.

> The `install' rule in my Makefile.in, as it currently stands,
> checks for an existing `${bindir}/lpr.exe', and moves it out of the
> way, (by making this a prerequisite of `install'):
>
>   # If the user has cygutils' `lpr.exe' installed,
>   # we move it out of the way.
>   #
>   install-lpr-basic:
>           if test -e ${bindir}/lpr.exe; then \
>             rm -f ${bindir}/lpr-basic.exe; \
>             mv ${bindir}/lpr.exe ${bindir}/lpr-basic.exe; \
>           fi

Hmmm.  I think I'd do it like this:

install-lpr-basic:
        if test -e ${bindir}/lpr.exe; then \
          if test -e ${bindir}/lpr-basic.exe; then \
            if cmp ${bindir}/lpr.exe ${bindir}/lpr-basic.exe >/dev/null ; then \
              rm ${bindir}/lpr.exe ;\
            else \
              mv ${bindir}/lpr.exe ${bindir}/lpr-old.exe ;\
            fi ;\
          else \
            mv ${bindir}/lpr.exe ${bindir}/lpr-old.exe ;\
          fi ;\
        fi

That is, if both .exes exist and are the same, then don't disturb
lpr-basic.exe -- just delete lpr.exe.  Otherwise (they differ, or
lpr-basic.exe doesn't exist), then move lpr.exe to lpr-old.exe -- don't
bother lpr-basic.exe or assume that lpr.exe IS lpr-basic.exe, when you
don't really know if that's the case.

>> Any comments on patching lpr.exe docu/--help to "advertise"
>> lpr-advanced?
>
> I'm happy to leave that to your discretion.

I'll go ahead an make the appropriate changes. It's possible that
lpr-basic's help and documentation might refer to 'lpr-enhanced' before
we finish packaging the latter, but I think that's ok since it will only
be a temporary situation.

Now, cygutils ships a man page for lpr. I'll install that one as
lpr-basic.1.

--
Chuck


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Friday 11 September 2009 15:52:20 Charles Wilson wrote:
> Oh, okay. Thanks for doing that. I see that about 8hours after you
> sent this email, that you created the initial CVS infrastructure
> with the (unchanged) files from the original lpr-1.0.1-msys
> package.

Yeah.  I wanted to capture the initial state, unmodified.

> However, the additional build infrastructure that you've
> (privately) developed and mention below is not yet there (no
> rush), so I'll wait before commenting further.

It's there now; mostly based on your contribution, with a few
cosmetic changes, but omitting the automake cruft, and adding a
Makefile.in in its place.  I've also omitted the NEWS file, not
because I object to it in principle, but if all it has to report
is release dates, does it really serve any useful purpose?  (IMO,
each release should be recorded in ChangeLog anyway).

> > The `install' rule in my Makefile.in, as it currently stands,
> > checks for an existing `${bindir}/lpr.exe', and moves it out of
> > the way, (by making this a prerequisite of `install'):
> >
> >   # If the user has cygutils' `lpr.exe' installed,
> >   # we move it out of the way.
> >   #
> >   install-lpr-basic:
> >           if test -e ${bindir}/lpr.exe; then \
> >             rm -f ${bindir}/lpr-basic.exe; \
> >             mv ${bindir}/lpr.exe ${bindir}/lpr-basic.exe; \
> >           fi
>
> Hmmm.  I think I'd do it like this:
>
> install-lpr-basic:
>         if test -e ${bindir}/lpr.exe; then \
>           if test -e ${bindir}/lpr-basic.exe; then \
>             if cmp ${bindir}/lpr.exe ${bindir}/lpr-basic.exe
> >/dev/null ; then \ rm ${bindir}/lpr.exe ;\
>             else \
>               mv ${bindir}/lpr.exe ${bindir}/lpr-old.exe ;\
>             fi ;\
>           else \
>             mv ${bindir}/lpr.exe ${bindir}/lpr-old.exe ;\
>           fi ;\
>         fi
>
> That is, if both .exes exist and are the same, then don't disturb
> lpr-basic.exe -- just delete lpr.exe.

My first thought was to do something like that, (although I didn't
think to run `cmp' on the pair).  My concern was that lpr.exe might
be a real executable, while (on Cygwin) lpr-basic.exe was a symbolic
link to it, (and would compare as identical); then when you delete
lpr.exe, you leave lpr-basic.exe as a dangling link.  (Of course, my
way breaks just the same, if the roles are reversed).  I've checked
it in as I wrote it, for now, but I guess we need a more robust
formulation before we release.

You may also notice that I've added make rules for the complete set
of distribution tarballs; I'd welcome opinions on the allocation of
files to the DOC_DISTFILES and LIC_DISTFILES groups:

  DOC_DISTFILES = README
  LIC_DISTFILES = AUTHORS COPYING

--

Regards,
Keith.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:
> It's there now; mostly based on your contribution, with a few
> cosmetic changes, but omitting the automake cruft, and adding a
> Makefile.in in its place.  I've also omitted the NEWS file, not
> because I object to it in principle, but if all it has to report
> is release dates, does it really serve any useful purpose?  (IMO,
> each release should be recorded in ChangeLog anyway).

For something like this, sure -- you don't really need it (and <sotto
voce>I only added it because automake required it...</me ducks>). The
value to me of the NEWS file, for very active projects, is I don't have
to wade thru six months' worth of commit records in gcc's ChangeLog to
learn that VTA support has been merged into gcc-4.5.0.

> My first thought was to do something like that, (although I didn't
> think to run `cmp' on the pair).  My concern was that lpr.exe might
> be a real executable, while (on Cygwin) lpr-basic.exe was a symbolic
> link to it, (and would compare as identical); then when you delete
> lpr.exe, you leave lpr-basic.exe as a dangling link.  (Of course, my
> way breaks just the same, if the roles are reversed).  I've checked
> it in as I wrote it, for now, but I guess we need a more robust
> formulation before we release.

The way I've configured the cygutils package for msys is that there are
two separate copies.  For cygwin...hmm.  I hadn't really considered
modifying the upstream cygwin version to install lpr.exe as
lpr-basic.exe there.  But if I were to do so, then I'd explicitly code
the Makefile rule to use a hardlink (which devolves to a copy on
FAT/SMB?/NFS?), never a symlink.

The typically approach on cygwin, when two packages provide the same
file, is for the "cygwin maintainers" (e.g. those who create and upload
packages to the cygwin mirror system) to cooperate, using the
alternatives system.  That is, in this situation:

   cygutils would install lpr as lpr-basic.exe, and would include a
postinstall script that specifies:
     /usr/sbin/update-alternatives --install \
     "${bindir}/lpr" "lpr" "${bindir}/lpr-basic.exe" 30

   lpr-enhanced would install lpr-enhanced directly, and would include a
postinstall script that specifies:
     /usr/sbin/update-alternatives --install \
     "${bindir}/lpr" "lpr" "${bindir}/lpr-enhanced" 40

But typically, the two cygwin maintainers would munge the $(STAGING)
image to ensure that the "real" file names don't conflict -- they
wouldn't expect the "real" package's Makefile/build structure to be
concerned about that.

Unfortunately, the alternatives system requires true symlink support...

> You may also notice that I've added make rules for the complete set
> of distribution tarballs; I'd welcome opinions on the allocation of
> files to the DOC_DISTFILES and LIC_DISTFILES groups:
>
>   DOC_DISTFILES = README
>   LIC_DISTFILES = AUTHORS COPYING

I think I'd put the AUTHORS file into the DOC package. The COPYING file
contains your name and the license/disclaimer. IMO that's sufficient,
since 99.40% of the work is yours.  The typical place for recognizing
other contributors is in the documentation...e.g. the -doc package.

'make bindist' didn't quite work. I modified as shown below.  My
proposed change is fine for msys and cygwin builds, but if you use the
mingw formulation where
        --prefix=`cd /mingw && pwd -W` \
        --sysconfdir=`cd /etc && pwd -W` \
        --localstatedir=`cd /var && pwd -W`
then it would break. But why would you want to do that?

Also, one of the commands left $CWD in the wrong place, so I put it in a
subshell.


One other comment: I'm not sure I'd want the -bin package to include
/etc/printcap.  Without scripting support in our installer, we really
can't automate the installation of configuration files, nor protect the
end-user against clobbering their customizations.  At least when
installing "live" we could protect an existing /etc/printcap by
installing the new one only as /etc/printcap.new if /etc/printcap
already exists.  But for the -bin package, so such luck.

Since we already install an example file in var/spool/lp/config/example,
and reference it in the README, I think it's probably best if we omit
/etc/printcap entirely from the -bin package.


But that's pretty much it. I'm not even that concerned if you leave the
current lpr-basic handling alone -- it's extremely common for "live"
'make install' to clobber pre-existing stuff in $(prefix); I'm not too
fussed about the current Makefile.in code in that respect.  So long as
the cygutils-msys-bin and lpr-enhanced-msys-bin packages don't
explicitly conflict, I'm happy, subject to:

1) attached patch, or some alternate solution
2) AUTHORS in -doc, unless you feel strongly about it
3) resolution of /etc/printcap issue

--
Chuck



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Saturday 12 September 2009 04:12:54 Charles Wilson wrote:
> The value to me of the NEWS file, for very active projects, is I
> don't have to wade thru six months' worth of commit records in
> gcc's ChangeLog to learn that VTA support has been merged into
> gcc-4.5.0.

Absolutely.  The value of the NEWS file, for *any* project, is to
provide an itemised summary of feature changes between releases.  If
we ever add new features to lpr-enhanced, then we can add a NEWS
file for this purpose.

> >   DOC_DISTFILES = README
> >   LIC_DISTFILES = AUTHORS COPYING
>
> I think I'd put the AUTHORS file into the DOC package. The COPYING
> file contains your name and the license/disclaimer. IMO that's
> sufficient,

Okay, thanks.  I was undecided, but I think I'll change it to:

  DOC_DISTFILES = README AUTHORS
  LIC_DISTFILES = COPYING

> 'make bindist' didn't quite work.

Arrrrgh!  It did for me, when I configured only with --prefix='', and
defaults for localstatedir and sysconfdir, but it breaks when I use
explicit --prefix=/usr --localstatedir=/var --sysconfdir=/etc.  
Thanks for your patch; I've applied it partially (see below), with
some comment changes.

> I modified as shown below.  My
> proposed change is fine for msys and cygwin builds, but if you use
> the mingw formulation where
>         --prefix=`cd /mingw && pwd -W` \
>         --sysconfdir=`cd /etc && pwd -W` \
>         --localstatedir=`cd /var && pwd -W`
> then it would break. But why would you want to do that?

I can't imagine; there's nothing in this package which can survive in
a pure mingw32 subsystem.

> Also, one of the commands left $CWD in the wrong place, so I put
> it in a subshell.

Huh?  I guess you mean:

  cd $(STAGED)${bindir}; rm -f lp lpr

The scope of the cd command *should* encompass only the following
commands on the same logical line in the Makefile, (the rm command
in this case).  If it persists beyond, then your implementation of
`make' is broken.  I've omitted that part of your patch, pending
further discussion.

> One other comment: I'm not sure I'd want the -bin package to
> include /etc/printcap.  Without scripting support in our
> installer, we really can't automate the installation of
> configuration files, nor protect the end-user against clobbering
> their customizations.  At least when installing "live" we could
> protect an existing /etc/printcap by installing the new one only
> as /etc/printcap.new if /etc/printcap already exists.  But for the
> -bin package, so such luck.

Good point.  Maybe we should just omit it from the installation
entirely.  If we do install it, then it should be conditional on a
prior `test -f' failing, and we should remove it from the staged
install, prior to cutting the bindist tarball.

--

Regards,
Keith.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:

> On Saturday 12 September 2009 04:12:54 Charles Wilson wrote:
>> The value to me of the NEWS file, for very active projects, is I
>> don't have to wade thru six months' worth of commit records in
>> gcc's ChangeLog to learn that VTA support has been merged into
>> gcc-4.5.0.
>
> Absolutely.  The value of the NEWS file, for *any* project, is to
> provide an itemised summary of feature changes between releases.  If
> we ever add new features to lpr-enhanced, then we can add a NEWS
> file for this purpose.

Sure.

> Okay, thanks.  I was undecided, but I think I'll change it to:
>
>   DOC_DISTFILES = README AUTHORS
>   LIC_DISTFILES = COPYING

Works for me.

>> 'make bindist' didn't quite work.
>
> ... I've applied it partially (see below), with
> some comment changes.

OK.

>> I modified as shown below.  My
>> proposed change is fine for msys and cygwin builds, but if you use
>> the mingw formulation then it would break. But why would you want to do that?
>
> I can't imagine; there's nothing in this package which can survive in
> a pure mingw32 subsystem.

Right.

>> Also, one of the commands left $CWD in the wrong place, so I put
>> it in a subshell.
>
> Huh?  I guess you mean:
>
>   cd $(STAGED)${bindir}; rm -f lp lpr
>
> The scope of the cd command *should* encompass only the following
> commands on the same logical line in the Makefile, (the rm command
> in this case).

Huh.  You're right.  I was just scanning the file to see what looked
right and what looked wrong, *before* testing.  Then, I documented what
I *had already* changed, *after* testing.  So that line never actually
failed as you originally coded it.

I just thought it would (and of course, it worked after I "fixed" it).

I never know about the scope of CWD changes in makefiles.  I told you I
wasn't good at hand-writing them.

>> One other comment: I'm not sure I'd want the -bin package to
>> include /etc/printcap.
>
> Good point.  Maybe we should just omit it from the installation
> entirely.  If we do install it, then it should be conditional on a
> prior `test -f' failing, and we should remove it from the staged
> install, prior to cutting the bindist tarball.

For a "live" install, it's your choice.  I'd lean towards omitting it,
because otherwise 'make uninstall' gets tricky.  You have to use cmp to
determine if the installed copy has been modified, and only uninstall it
if it is identical to the one in $(srcdir).

For the bindist, definitely needs to be omitted from the package.

Lookin' good...

--
Chuck

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[keithmarshall]

On Monday 14 September 2009 23:24:57 Charles Wilson wrote:

> >> One other comment: I'm not sure I'd want the -bin package to
> >> include /etc/printcap.
> >
> > Good point.  Maybe we should just omit it from the installation
> > entirely.  If we do install it, then it should be conditional on
> > a prior `test -f' failing, and we should remove it from the
> > staged install, prior to cutting the bindist tarball.
>
> For a "live" install, it's your choice.  I'd lean towards omitting
> it, because otherwise 'make uninstall' gets tricky.  You have to
> use cmp to determine if the installed copy has been modified,

Sure, but...

> and only uninstall it if it is identical to the one in $(srcdir).

...better, perhaps, to compare with the sample installed at the same
time, in ${localstatedir}/spool/lp/config/example.

> For the bindist, definitely needs to be omitted from the package.

I've committed another round of changes, addressing this and other
issues we've discussed.  I think it's now ready for release.  I've
attached the manifest, with `make dist SNAPSHOT=-1'; any further
comments, before I push it to FRS?

--

Regards,
Keith.




lpr-enhanced-1.0.2-1-msys-1.0.11-bin.tar.lzma:
drwxr-xr-x keith/keith       0 2009-09-15 21:26 bin/
-rwxr-xr-x keith/keith   13684 2009-09-15 21:26 bin/lp
-rwxr-xr-x keith/keith   13684 2009-09-15 21:26 bin/lpr
-rwxr-xr-x keith/keith   13684 2009-09-15 21:26 bin/lpr-enhanced
drwxr-xr-x keith/keith       0 2009-09-15 21:26 etc/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 var/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 var/spool/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 var/spool/lp/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 var/spool/lp/debug/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 var/spool/lp/config/
-rw-r--r-- keith/keith    5020 2009-09-15 21:26 var/spool/lp/config/example
drwxr-xr-x keith/keith       0 2009-09-15 21:26 var/spool/lp/tmp/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 var/spool/lp/log/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 var/spool/lp/filter/

lpr-enhanced-1.0.2-1-msys-1.0.11-doc.tar.lzma:
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/share/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/share/doc/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/share/doc/lpr-enhanced/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/share/doc/lpr-enhanced/1.0.2-1/
-rw-r--r-- keith/keith     160 2009-09-03 09:59 usr/share/doc/lpr-enhanced/1.0.2-1/AUTHORS
-rw-r--r-- keith/keith    3653 2009-09-10 13:08 usr/share/doc/lpr-enhanced/1.0.2-1/README

lpr-enhanced-1.0.2-1-msys-1.0.11-lic.tar.lzma:
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/share/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/share/doc/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/share/doc/lpr-enhanced/
drwxr-xr-x keith/keith       0 2009-09-15 21:26 usr/share/doc/lpr-enhanced/1.0.2-1/
-rw-r--r-- keith/keith     385 2009-09-03 09:59 usr/share/doc/lpr-enhanced/1.0.2-1/COPYING

lpr-enhanced-1.0.2-1-msys-1.0.11-src.tar.lzma:
drwxr-xr-x keith/keith       0 2009-09-15 21:26 lpr-enhanced-1.0.2/
-rw-r--r-- keith/keith     809 2009-09-10 09:57 lpr-enhanced-1.0.2/configure.ac
-rwxr-xr-x keith/keith   13620 2008-02-08 14:49 lpr-enhanced-1.0.2/install-sh
-rw-r--r-- keith/keith     160 2009-09-03 09:59 lpr-enhanced-1.0.2/AUTHORS
-rw-r--r-- keith/keith   13780 2009-09-08 14:19 lpr-enhanced-1.0.2/lpr-enhanced.sh
-rwxr-xr-x keith/keith   86160 2009-09-10 10:02 lpr-enhanced-1.0.2/configure
-rw-r--r-- keith/keith     385 2009-09-03 09:59 lpr-enhanced-1.0.2/COPYING
-rw-r--r-- keith/keith    3594 2009-09-15 21:21 lpr-enhanced-1.0.2/ChangeLog
-rw-r--r-- keith/keith    5042 2009-09-03 15:34 lpr-enhanced-1.0.2/example.in
-rw-r--r-- keith/keith    7234 2009-09-15 14:45 lpr-enhanced-1.0.2/Makefile.in
-rw-r--r-- keith/keith    3653 2009-09-10 13:08 lpr-enhanced-1.0.2/README

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

Keith Marshall wrote:

> On Monday 14 September 2009 23:24:57 Charles Wilson wrote:
>> For a "live" install, it's your choice.  I'd lean towards omitting
>> it, because otherwise 'make uninstall' gets tricky.  You have to
>> use cmp to determine if the installed copy has been modified,
>
> Sure, but...
>
>> and only uninstall it if it is identical to the one in $(srcdir).
>
> ...better, perhaps, to compare with the sample installed at the same
> time, in ${localstatedir}/spool/lp/config/example.

right.

>> For the bindist, definitely needs to be omitted from the package.
>
> I've committed another round of changes, addressing this and other
> issues we've discussed.  I think it's now ready for release.  I've
> attached the manifest, with `make dist SNAPSHOT=-1'; any further
> comments, before I push it to FRS?

Yes, I "rebuilt" the packages from CVS and everything seems fine. Go for
it.  This sure has been an adventure...

--
Chuck

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr