Most printer (or print server box) manufacturers totally ignore the details of the RFC1179 protocol and simply accept the data files for printing, disregarding the control file until they need to print a banner or provide status information.
At this point, you suddenly discover all sorts of little details that cause horrible problems. For example, the use of non-ASCII characters (i.e. - values are 128-255) in the J (job) line of a control file has been known to crash one network interface card in such a manner that a power-up is needed to restart the printer.
Also, if you send one particular RFC1179 compatible print spooler a control file with a character whose value is 255 (i.e. 0xFF), the job will never get printed, and there is a mysterious diagnostic on the console:
unexpected end of input
This is due to the fact that the 0xFF eight bit value is getting sign extended to a 16 bit value 0xFFFF, which just turns out to be -1, or the error indication from a read.
For various reasons, some versions of the OS/2 lpd
print spooler have decided to make the control file and data file names
have different formats.
In addition, the OS/2 spooler does not follow RFC1179 correctly, and truncates the data and job file protocol exchange.
There is the subtle and nasty problem with some print filters that are not meta-char-escape proof. For example, suppose that a user decided to spool a job as follows:
lpr '-J; rm -rf /*;' /tmp/a
This would create a job file with the line:
J `rm /etc/passwd; echo Job;`
The job line ends up getting passed to a print filter:
pr:sd=/...
:if=/usr/local/hack
... invoked as:
/usr/local/hack '-J; rm -rf /*;'
/usr/local/hack is:
#!/bin/sh
while [ -n "$1" ] ; do
case "$1" in
-J ) shift; args="$args -M$1";;
esac;
shift;
done;
# reformat the command line
eval /usr/local/realfilter $args
^^^^
The observant reader will notice that the above line gets expanded to:
eval /usr/local/realfilter -MJ; rm -rf /*;