bug in the CUPS lpr client

[Helge Blischke]

Nathan wrote:
> Hello,
> I apologize for the cross posting, I didn't get a response from the general list. I am having some problems with the lpr command while printing to a remote lpr server, it really appears to be a bug in the CUPS lpr client while generating the control file. I am speaking lpr protocol to the remote host, not IPP protocol. This is a RedHat packaged CUPS installation with rpm's cups-1.1.17-13.3.37 and cups-libs-1.1.17-13.3.37.
> 
> I am using this command to print to a remote lpr server:
> lpr -Pprinter -JABCD -C1234 /tmp/print.txt
> 
> So, print jobs make their way to the remote lpr server and are accepted ok. However lpr is hacking up my -J and -C flags when building the lpr control file. These are of course arbitrary values that only have meaning at the remote lpr server. In this case -JABCD is a printer name -C1234 is a formatting code for landscape.
> 
> I did a tcpdump and found that lpr only sends the last job name flag on the command line and marks it as a value for "J" no matter which job name flag I use (-J, -C, and -T are all listed as job name flags in the CUPS lpr man page).
> 
> Control file structure that I am expecting from the command above (Please correct me if I am wrong):
> Hmyhost.somewhere.edu
> Proot
> JABCD
> C1234
> ldfA010myhost.somewhere.edu
> UdfA010myhost.somewhere.edu
> N/tmp/print.txt
> 
> What I am getting:
> Hmyhost.somewhere.edu
> Proot
> J1234
> ldfA010myhost.somewhere.edu
> UdfA010myhost.somewhere.edu
> N1234
> 
> 
> I've been referencing rfc 1179 to interpret the packets and understand the control file:
> http://www.ietf.org/rfc/rfc1179.txt
> 
> 
> Other Unix platforms (AIX/non CUPS) support these flags just fine and don't seem to mangle them. Any assistance would be appreciated.
> 
> Thanks!
> -Nathan
> 

I suspect this is rather a feature than a bug, as the handling of these items
is quite different with different LPD implementations.

If you like, you can get a Perl script that may be used with slight modifications
as a replacement for the lpd backend.

Let me know if this is an option for you.

Helge


-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de