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