Get APLawrence.com by RSSRecent SCO/Linux News
From: "Brian K. White" <br...@aljex.com> Subject: Re: Printer Alias? Date: Fri, 5 Oct 2007 06:01:48 -0400 ----- Original Message ----- From: "Chris Schmidt" <cschm...@unidos.com> Subject: Printer Alias? >I am trying to get an app (Datamodes) on OSR6 to print output through > UnForm. I have come across this about a "printer alias" but not sure > how it works or where it would become part of the system config. See > below: > >>From the Unform 7 Manual: > > UNIX Aliases > A printer alias line on UNIX generally pipes to a program, such as the > uf70c client program. This client > program in turn can pipe its output to the spooler, or to a file, or > it can instruct the server to handle the > output from its end, by specifying the -o option. > Here is a sample alias line that pipes through UnForm to the local > spooler: > alias P1 "|uf70c -f my.rul | lp -dxyz -oraw -s 2>/dev/null" "Printer > Name" ... various modes ... > Here is a sample alias line that instructs the server to print the job > to its spooler. The advantage of this > type of configuration is that the client doesn't have to wait for the > job to finish. It submits the job to the > server and exits quickly. > > alias P1 "|uf70c -f my.rul -o \'>lp -dxyz -oraw\'" "Printer Name" ... > various modes ... > > Note the use of the -oraw option in the above examples. It is > important for UnForm's output to be > handled as binary data by the spooler. The -oraw option is used by > some UNIX spoolers, such as the > SCO LaserJet model script, and the CUPS printing system. Other > spoolers require different options, > such as "-o-dp" for AIX, -T pcl for Unixware, -b for some older Linux > installations. Check your lp > configuration tools or man pages for the appropriate settings for > options such as "binary", "raw", or > "pass-thru" printing. > > UnForm can also print directly to a device, as in this example: > > alias P1 "|uf70c -f my.rul -o /dev/lp0" "Printer Name" ... various modes > ... > > Note that this line will behave differently with the UnForm pipe than > without. When opening and > sending output directly to a device, printing will occur immediately, > without closing the device. > However, with the pipe to UnForm, the output will not appear until the > device is closed. The > application may need to be modified to account for this if UnForm is > to be used in this circumstance. > > > > My Question is, where exactly would this "alias" command take place in > OSR6 to make it work? Just at the command line? /etc/printcap? > CUPS? We are using CUPS BTW. > > If you know of a link that will help me better understand this please > post it. > > > Thanks, > > Chris > Unidos Inc. That is just an example for how to inject unform into one particular common language that many legacy apps are written in. In that case the language is BBx by Basis Inc. (Later versions are called PRO/5) The example is specific to bbx, yet still serves as an example for any other kind of app. They are just saying, "Here is a sample unform command, it takes data on stdin, and outputs to /dev/lp0 if you use the option -o /dev/lp0. Insert this command into the pipeline wherever/however your application defines it's printers. Here is how you'd do it in a bbx app." "alias P1 etc...." is syntax for the config.bbx file in BBx or PRO/5 "config.bbx" might not be named config.bbx. It might be named anything and might live in any directory. The name & location is variable/configurable. And generally you don't edit it directly but use some screen in your application that knows how to regenerate it. There are lot's of quirks about config.bbx that aren't obvious and it's easy to make a perfectly good looking utterly broken config file, which would then prevent you from being able to start up the application to use it's config file maintenance screen to regenerate a valid file. Most apps have some similar kind of config file where printers that are defined. For example, assume you have a typical old app written in BBx, and assume the app does not have a config.bbx maintenance module and that it's ok to just edit the file directly. In this app, the bbx config file might be /usr/bbx3/config.bbx This file file might have a few printers defined in it. [...] #alias LP ">lp -dprnlp -s 2>/dev/null" "132 column parallel" CR #alias P0 /dev/lp1 "132 column parallel" CR,LOCK=/usr/spool/lpd/p0 alias P1 ">lp -d m1 -s -o nff 2>/dev/null" "OneCall upstairs matrix" CR alias P2 ">lp -d m2 -s -o nff 2>/dev/null" "OneCall downstairs matrix" CR alias P3 ">lp -d m3 -s -o nff 2>/dev/null" "Clipper matrix" CR #alias P2 /dev/ttyi07 "132 column serial" CR,LOCK=/usr/spool/lpd/p2 #alias P3 ">lp -dprnp3 -s 2>/dev/null" "132 column serial" CR #alias P3 /dev/tty "Printer A" cr,bs,pton=5B3469,ptoff=5B3569 #alias P3 /dev/tty "Printer B" cr,bs,pton=5B3669,ptoff=5B3769 #alias P3 /dev/tty "Printer C" cr,bs,pton=5B3869,ptoff=5B3969 #alias P4 /dev/ttyi01 "132 column serial" CR,LOCK=/usr/spool/lpd/p4 #alias P5 /dev/ttyi00 "132 column serial" CR,LOCK=/usr/spool/lpd/p5 [...] In this case only P1, P2, P3 are in effect, the rest are commented out, but they serve to show some valid examplesthat do work and do things that are needed in other situations. This is just the printers, there is lot's of other stuff in the file, including some values that would need to be recalculated if I were to add/uncomment a new printer line. And, I had better be sure that I didn't exceed my license count for number of terminals/printers or else the app won't start. Each line is space-delimited (so if a field needs to include spaces, it must be quoted), and the 3rd field of each line is the print destination. In the case of BBx, the default assumption about the contens of that field is that it contains a device name, like /dev/lp0 or /dev/tty1a for the first parallel or the forst serial port respectively. In order to Make BBx pipe data into a command (like a spooler print queue) instead of writing directly to a raw device, you have to use a special syntax to tell it so. It happens that in the old version of bbx that my sample app is using, the correct syntax for piping data into the printer command is ">command...", not "|command..." which was used in the uform example you posted. Later versions of bbx (PRO/5) do use the "|command..." syntax. Let's say I wanted to add a printer that would show up in the app as P4 and use UnForm. (note there are often naming rules/restrictions in bbx as to what you can use for a printer or terminal alias or else bbx (or maybe it's the applications not bbx itself) won't recognize the line as a valid alias, so, unfortulately, you can't name the printer "unform", besides, this needs to be typed-in a lot so it needs to be short, but even UF or U or PU may not work, so, P# is a safe example that always works) I might add this line: alias P4 "|uf70c -f my.rul -o /dev/lp0" "UnForm to lp0" cr That's all very bbx-specific stuff. You are probably meant to read that, and only take away the general usage example and translate it to whatever you need for your own app. For example, I used to use bbx and still help a few people here & there (which is why I know any of the above), but I mostly write in filePro not bbx. filePro has it's own config file with a similar set of lines for defining printers. The fp config file is also variable/configurable and might be named anything and live anywhere, and whoever wrote/sold/admins the app, or is at least familiar with the language, will know where it is or how to find it. A typical example is /u/appl/fp/lib/config In there might be the following lines (taken from the same real system as above, which really has both a bbx and a filepro app on it, using the same printers & print queues, so you can see real correlatios and differences): printer1=hplaser,hp-4+,lp -d hplaser -s -o raw,Main Laser Printer printer2=m1,ibmpro,lp -d m1 -s -o nff,Matrix Upstairs printer3=m2,ibmpro,lp -d m2 -s -o nff,Matrix Downtairs printer4=m3,ibmpro,lp -d m3 -s -o nff,Matrix at Clipper This defines 4 printers in filePro named hplaser, m1, m2, m3. which are the same names as the unix print spools they map to. In the case of filepro, the line is comma-delimited not space delimited, and the 3rd field contains the print destination. Just the oppisite of BBx, the field is assumed to contain a command of some sort and the print data is piped into it, not a raw device, and so there is no > or | at the beginning of the field. If I did want to write directly to a raw device then I'd have to use ">/dev/foo" instead of "lp -d foo" If I wanted to add a 5th printer that used UnForm and ultimately went to the hplaser printer, I might add this line: printer5=unform,unform,uf70c -f my.rul |lp -s -d hplaser -o raw,UnForm to Main Laser Printer This defimes a new printer, printer number 5, named unform, using a print-code table also named unform (which I'd presumably have written by taking a copy of the "hp-4+" print code table that the hplaser printer uses, and add special unform codes to that, which unform would then recognize and act upon.) There is now a | in the print destination field because now the field contains two commands, one piped into the other. The whole thing can be treated as one big command but it's really the original printer1 command "lp -d foo" with unform inserted before the spooler to make the new command "unform ... |lp -d foo" I had to assume several things there because I really don't know anything about unform and am not going to go research it now. I'm assuming, based on the example given in the unform docs, that unform is a filter of some sort and still expects to output to a printer. The example you posted from the unform docs points the output right at a raw device /dev/lp0. That almost certainly means UnForm is assuming that nothing else on the system ever touches /dev/lp0 so that unform is free to write to it whenever it wants. This means "uf70c" is taking the place of "lp" as the spooler for that device, and you shouldn't have any printers defined in unix that have /dev/lp0 as their target device, if you were going to use that example. I on the other hand am assuming that all printer devices are configured into the system and have spooler queues and that unform also allows you to print to a configured print spool instead of to a raw device. I assumed that unform maybe prints to stdout by default if you simply omit the -o option. It's just as likely that -o is always required and that to print to stdout instead of a file or device, you use "-" in place of a file or device name. In that case the filepro config line would have been: printer5=unform,unform,uf70c -f my.rul -o - |lp -s -d hplaser -o raw,UnForm to Main Laser Printer A cobol3 application I happen to encounter a lot defines it's printers by setting some environment variables in the users environment in the start script that launches the app or in the users .profile etc... like so: dd_LPT0="> /usr/bin/lp -s -d LPT0" dd_LPT1="> /usr/bin/lp -s -d LPT1" dd_SAVIN="> /usr/bin/lp -s -d main" dd_OKI="> /usr/bin/lp -s -d OKI" dd_SCREEN="> /usr/bin/mpg -c" dd_FAX="> /usr/vsifax/bin/fx -N -s" dd_FILE="/tmp/FILE" dd_LOCAL="> /usr/bin/lprint" dd_EMAIL="EMAIL" export dd_LPT0 dd_LPT1 dd_SAVIN dd_OKI dd_SCREEN dd_FAX dd_FILE dd_LOCAL dd_EMAIL so to inject unform I'd just edit one of those defines. dd_UNFORM="> /path/to/uf70c -f my.rul \| /usr/bin/lp -s -d main" export dd_UNFORM Note, I don't know if it's cobol itself or the application that reads these variables. cobol3 may have some config file roughly similar to bbx and filepro and it may be the application that is reading these variables. ... in fact now that I look I do see a file /u/cobol3/cobcap which contains: LPT0:W:/usr/bin/lp:-s:-dLPT0: LPT1:W:/usr/bin/lp:-s:-dLPT1: OKI:W:/usr/bin/lp:-s:-dOKI: SCREEN:W:/usr/bin/mpg:-c: FAX:W:/usr/vsifax/bin/fx -N:-s: FILE:W:/bin/cat: > /tmp/FILE: LOCAL:W:/usr/bin/lprint: It looks like each command line argument to the spoler command is seperated in it's own colon-delimited field, and yet, there are also single fields that do contain spaces and multiple command line arguments, including at least one redirection (>) that isn't escaped or anything, so, I _guess_ you could add a line like this: UNFORM:W:/path/to/unform -f my.rul |/usr/bin/lp:-s:-d main: it might also be intended and more correct to just take every "word" of the command and treat the line as colon-delimited instead of space-delimited like usual, and spaces within a single field would not need to be quoted, and you can just have as many fields as you want and only the first two are special, so it would look like this UNFORM:W:/path/to/unform:-f:my.rul:|:/usr/bin/lp:-s:-d:main: That actually makes sense if you imagined a print command that used a field that had spaces in it, like ACCT:W:/bin/mail:-s:Urgent message for the accounting department!:account...@mycompany.com: There are several other common languages/systems that legacy apps are written in which I have no idea how their printers are configured but whoever wrote/sells/administers the app does know, and knows how to take the PRO/5 example from the unform docs (and these others I just made up) and do the equivalent in their system. It's also possible to configure a unix printer that uses unform all the time right in the unix spooler and not do anything in the application config at all (other than, presumably, start adding special strings into the print data that unform recognizes and acts upon). You do that by editing the printer interface script (on OSR5 it's a shell script in /usr/spool/lp/admins/lp/interfaces/printername). On other OS's and/or in other spooling software, the equivalent of the printer interface script is in various places and takes various forms, including actually one of your guesses /etc/printcap, although usually you do not actually use printcap for this kind of thing even though there IS a "filter" field in printcap that is intended for roughly this sort of usage. It's just that most spooler software like the stock osr5 lp spooler or cups or lprng or apsfiletrs etc all have some much more flexible way of doing this kind of stuff and you do it in there instead of in printcap. We would have to know what your app was, and what system/language it's written in, and what you were trying to accomplish, in order to suggest where and how (or even IF) to insert unform into the mix. Brian K. White br...@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!