Multiplexed printing is missing from all Unix/Linux printing systems that I know of. If you want to print to printer "Main" and have the output appear on two different physical printers, there's no way to specify that when creating "Main".
I don't mean printer classes, where you want "Main" to pick an available printer from a pool. I mean where you want one print command to appear on two or more physical devices.
Obviously you could do this with a simple shell script:
lp -d printer1 "$@" lp -d printer2 "$@" lp -d printer3 "$@"
If you called that "threeprint", you could say "threeprint myfile" and you'd get it on all three printers. You'd need to remember to do that though, and it could be difficult to convince some application programs to use your script instead of "lp".
You could "front-end" lp. That is, you could replace the system lp with your own script that parses the arguments and normally just passes them on to the original lp command that you have hidden away somewhere, but watches for a special printer name and handles that by sending it to multiple printers. That can work, but system upgrades would break it easily, and you have to parse arguments carefully in your script.
So, what we really want to do is make lp do the work for us. With System V printing, that's very easy, and since Cups can use Sys V interfaces, we can use the same script on Linux and Mac OS X.
The script itself can be very simple if you don't care about optional parameters. That's often the case when the "printer" will only be used by some application that won't pass any options like number of copies or orientation. If that's true, something like this will work:,
#!/bin/bash # if you don't have bash, use /bin/sh # don't leave off the first line - absolutely needed for cups! /usr/bin/lp -dprinter1 $6 /usr/bin/lp -dprinter2 $6 /usr/bin/lp -dprinter3 $6
For SysV and Cups, that's your "interface" file. You'd create a new printer like this:
# System V chmod 755 ~/myinterfacefile cp ~/myinterfacefile /var/spool/lp/model /usr/lib/lpadmin -p threeprint -m myinterfacefile -v /dev/null /usr/lib/accept threeprint enable threeprint
There's a little less work for Cups:,
# Cups chmod 755 ~/myinterfacefile lpadmin -p threeprint -E -i ~/myinterfacefile -v /dev/null
Sending jobs to "threeprint" (lp -d threeprint somefile) will now print on all three printers. If you did need to process the number of copies to print, the script isn't much different:
#!/bin/bash # don't leave off the first line - absolutely needed for cups! /usr/bin/lp -dprinter1 -n$2 $6 /usr/bin/lp -dprinter2 -n$2 $6 /usr/bin/lp -dprinter3 -n$2 $6
However, after that, there are differences between System V and Cups. The easiest way to see these is to add a little logging function to our script:
#!/bin/bash # don't leave off the first line - absolutely needed for cups! for i in "$@" do echo $i done > /tmp/mylogfile /usr/bin/lp -dprinter1 -n$2 $6 /usr/bin/lp -dprinter2 -n$2 $6 /usr/bin/lp -dprinter3 -n$2 $6
Let's test it out:
date > /tmp/t lp -dthreeprint -n2 -o landscape /tmp/t
On System V printing, we'll end up with something like this in our log:
threeprint-7 root 2 landcape /tmp/t
On Cups, it's different. This was from my Mac OS X machine:
509 apl t 2 finishings=3 number-up=1 landscape job-uuid=urn:uuid68d98a7c-87da-3f42-61ec-7726392ebb14 /private/var/spool/cups/d00509-001
We have everything we need, but some of it is in different variables, so we'd need to write the script differently.
I know someone is bound to ask "Why didn't you use a backend script?". You absolutely could, but that involves putting the script into /usr/libexec/cups/backend/ and restarting cups. As we aren't doing a darn thing that needs any other functionality we could get with a backend script, why go to all that trouble? The interface file method works just as well, and requires no restart of Cups.
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Increase ad revenue 50-250% with Ezoic