SCO Unix/System V Printing FAQ
© Anthony Lawrence, aplawrence.com
This article is from a FAQ concerning SCO operating systems. While some of the information may be applicable to any OS, or any Unix or Linux OS, it may be specific to SCO Xenix, Open There is lots of Linux, Mac OS X and general Unix info elsewhere on this site: Search this site is the best way to find anything.
First, are you really sure you need to do this? Only very lame software can't handle a spooled printer. However, if you must:
The basic concept is to create a named pipe. For example, you might do this:
mknod /dev/myfakenetprint p
That creates a "device" that your application can print to. Use "chmod" as necessary to give it whatever permissions you need (666 if everyone needs to use it).
Now you need something that runs all the time in background. It's a shell script (see New to Unix if you don't know how to make a shell script) and it needs to start automatically whenever the machine is rebooted (see Automating Program Startup). This script assumes that your network printer already exists in the spooler:
while true do cat /dev/myfakenetprint | lp -dmyrealnetprinter done
Some folks have found that this works better in some places:
while : do exec </dev/myfakenetprint lp -dmyrealnetprinter done
You could also use hpnpf or netcat (see Network Printing ) directly:
while : do cat /dev/myfakenetprint | netcat -h printername -p 3001 done Or: while : do exec </dev/myfakenetprint netcat -h printername -p 3001 done
These work because the "cat" will hang until something (your application) writes data to the named pipe. The "lp" won't complete until cat is done reading, which will be when your application closes its writing. Although it might look like this ties up your cpu, it doesn't- the cat sleeps while it hangs, and so does lp or netcat: there's nothing going on until you write data to the named pipe. If switching from a serial environment, you may find How can I assign a user process to a specific pseudo tty? useful also.
On a very busy system, it's possible for the writing process to send new data to the pipe before your reader process has sent it to the print server. You could implement a cooperative locking system to prevent that, but a small sleep at the end of the interface script will probably work.
You can use this same concept to implement "printers" that send email, queue faxes or do anything else you need done.
See Race conditions also.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version