Dual printing

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.

See Using System V interface scripts with CUPS printing also.

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Need eyes on the ground at your customer's site?
Installation and light training Boston and New England
Reliable and experienced, punctual and professional.

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here