From: Charles W. <cwi...@us...> - 2009-08-27 18:54:50
|
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. |
From: Keith M. <kei...@us...> - 2009-08-27 21:52:53
|
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. |
From: Charles W. <cwi...@us...> - 2009-08-27 23:41:15
|
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 |
From: Keith M. <kei...@us...> - 2009-08-28 22:13:20
|
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. |
From: Charles W. <cwi...@us...> - 2009-08-28 23:32:25
|
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/gr...@gn.../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 |
From: Keith M. <kei...@us...> - 2009-09-03 19:52:12
|
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/gr...@gn.../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. |
From: Charles W. <cwi...@us...> - 2009-09-03 21:36:48
|
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 |
From: Keith M. <kei...@us...> - 2009-09-10 21:52:56
|
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. |
From: Charles W. <cwi...@us...> - 2009-09-11 14:52:34
|
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 |
From: Keith M. <kei...@us...> - 2009-09-11 21:27:12
|
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. |
From: Charles W. <cwi...@us...> - 2009-09-12 03:13:11
Attachments:
lpr-enhanced-bindist.patch
|
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 |
From: Keith M. <kei...@us...> - 2009-09-14 21:28:22
|
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. |
From: Charles W. <cwi...@us...> - 2009-09-14 22:25:33
|
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 |
From: Keith M. <kei...@us...> - 2009-09-16 16:32:39
Attachments:
dist.lst
|
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. |
From: Charles W. <cwi...@us...> - 2009-09-16 17:43:30
|
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 |