Bug 58980 - lpr -Z options do not work
Summary: lpr -Z options do not work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: printconf (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
: 56834 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-01-28 21:12 UTC by Bill Seligman
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-06 14:08:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bill Seligman 2002-01-28 21:12:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-21 i686)

Description of problem:
I've got a Redhat 7.2 installation on a typical Intel box with all the latest
updates.  In particular, I've got the following RPMs installed:


I used the printconf-gui to select the HP4550 Postscript driver.  I can print
with lpr -- but I can't control the printer using any lpr options.

For example, according to the foomatic documentation, I should be able to do
something like this:

lpr -Php4550 -Zduplex -Zinlower myfile.ps

But while the file prints, it does _not_ print in duplex and prints from the
standard input bin.  For my users, this is not acceptable; they have to be able
to control the printer from the command line.

I've tried various alternative options; e.g.,

lpr -Php4550 -ZDuplex=On myfile.ps

I've also tried things like -ZDuplex, -JDuplex, -Z"Duplex On", and many other
variants.  The command

lpr -Zdocs -Php4550 /etc/inittab

just prints the file without displaying any options.

The relevant lines from /etc/printcap (as set by printconf-gui) are:


I've twiddled with mf_wrapper to see what's going on.  I've been able to
establish that the "-Z" options are being put into the /var/spool/lpd/hp4550/cf*
file.  "mf_wrapper" issues a "/usr/bin/magicfilter-t" command, and the "-Z"
options are part of the command.

But when I look at the output of magicfilter-t, I can that the postscript
commands that it creates do not change no matter which -Z option is passed to

Any ideas?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use printconf-gui to setup a Postscript driver for an HP printer (I've tried
HP4550 and HP4100)
2. lpr -Php4550 -Zduplex myfile.ps (or some variant)

Actual Results:  The file prints, but with none of print options that were

Expected Results:  The print options should take effect.

Additional info:

Comment 1 Bill Seligman 2002-02-05 17:35:50 UTC
I finally (after about three more days of pain and effort) found a
solution to this problem on my own.  The problem is that the version of
magicfilter-t in the printconf RPM is not compatible with lpdomatic in
the foomatic RPM.

As near as I can figure (I'm neither an expert in printconf, foomatic,
nor python), the printing sequence in the updated Redhat 7.2
distribution runs as follows:

1) lpd reads /etc/printcap and sends options to

2) mf_wrapper reads some m4 macros and constructs a
/usr/bin/magicfilter-t command with those options;

3) magicfilter-t, examining the filters passed to it, invokes

4) mf_postscript_wrapper invokes /usr/sbin/lpdomatic.

"magicfilter-t" read options from its command line -- but does not pass
those arguments to mf_postcript_wrapper (which is written as though it
expect them).  Instead, it sets some environment variables, $ZOPT for

However, lpdomatic does not access those environment variables; it
expects the options to come in on its command line.

The following patches are a brute-force solution to the problem.  They
force the file /var/spool/lpd/<queue>/mf.cfg to pass the options from
mf_wrapper to mf_postscript_wrapper.

As for me, I'm switching to CUPS.  It's flakey, unreliable, and hard to
configure -- but it's all of one piece, and it knows how to interpret a
standard PPD file.

The following patches are meant to be applied in /usr/share/printconf. 
After they're applied, it's necessary to run printtool (or
printconf-gui), click on the "Driver Options" tab of the relvant print
queue, then click the "Apply" button.  After that, the -Z options will

> diff -ru util/mf_wrapper.original util/mf_wrapper
--- util/mf_wrapper.original    Mon Feb  4 11:48:34 2002
+++ util/mf_wrapper     Mon Feb  4 13:52:47 2002
@@ -8,7 +8,16 @@
 TMP_FILE=`mktemp /tmp/printconf.XXXXXX` || exit 1
-cat ./mf.cfg $MF_RULES | m4 > $TMP_FILE
+# Create an m4 rule to pass the options to lpdomatic
+# via magicfilter.
+OPT_FILE=`mktemp /tmp/printopt.XXXXXX` || exit 1
+echo -n "define(LPRNGOPTS, " > $OPT_FILE
+echo -n ""'`'"" >> $OPT_FILE
+echo -n "$*" >> $OPT_FILE
+echo "')dnl" >> $OPT_FILE
+cat $OPT_FILE ./mf.cfg $MF_RULES | m4 > $TMP_FILE

 # Find the effective language set to use.
@@ -45,12 +54,15 @@

 # Run magic filter
-/usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING $* < /dev/stdin
+/usr/bin/magicfilter-t $TMP_FILE $DEBUGSTRING < /dev/stdin

 if [ -f $TMP_FILE ]; then
        rm -f $TMP_FILE;
+if [ -f $OPT_FILE ]; then
+       rm -f $OPT_FILE;

 if [[ $RETVAL -eq 0 ]]; then
        TERMINATION=`grep '^[[:space:]]*#[[:space:]]*TERMINATION='
./mf.cfg | sed 's/^[[:space:]]*#[[:space:]]*TERMINATION=//;'`

> diff -ru util/printconf_backend.py.original util/printconf_backend.py
--- util/printconf_backend.py.original  Mon Feb  4 13:27:37 2002
+++ util/printconf_backend.py   Mon Feb  4 13:27:11 2002
@@ -260,6 +260,9 @@
 make_mfomatic_perl_str = r"""

 $postscript_wrapper =
+# This complex string, when appended to the postscript_wrapper,
+# passes the contents of the LPRNGOPTS variable to lpdomatic.
+$lprng_opts = "'``LPRNGOPTS''`";

 undef $/;
 umask 0077;
@@ -376,7 +379,7 @@
                $text_filter = 'text "" \r\n\14 ';

-       $ps_filter = "filter $postscript_wrapper $rerender_ps --mfomatic
+       $ps_filter = "filter $postscript_wrapper $lprng_opts
$rerender_ps --mfomatic $gs_driver-$printer_id.foo";
        # Yes, this is stupid. But we don't have reliable information
anywhere on #dnl
        # if a given printer supports pcl and pjl, so what ya gonna do?
        $pcl_filter = 'cat';

Comment 2 Tim Waugh 2002-02-05 18:33:10 UTC
Thanks for the patch!  I think that this part:

OPT_FILE=`mktemp /tmp/printopt.XXXXXX` || exit 1
echo -n "define(LPRNGOPTS, " > $OPT_FILE
echo -n ""'`'"" >> $OPT_FILE
echo -n "$*" >> $OPT_FILE
echo "')dnl" >> $OPT_FILE

would be better written as:

OPT_FILE=`mktemp /tmp/printopt.XXXXXX` || exit 1
echo 'define(LPRNGOPTS, `'$*"')dnl" > $OPT_FILE

Comment 3 Bill Seligman 2002-02-05 18:43:02 UTC
If the $* macro gets interpreted within single quotes, then that's fine.

I was in constant pain trying to get the backtick within the string, and I
finally gave up.

Comment 4 Tim Waugh 2002-02-05 18:49:54 UTC
Okay (it does).  Also, there was a modification needed in the $mf_type eq
'POSTSCRIPT' case too.  I've applied this in the CVS tree.

Thanks for getting this working!

Comment 5 Tim Waugh 2002-02-15 08:54:43 UTC
Fix built as printconf-0.3.68-1.

Comment 6 Tim Waugh 2002-03-06 12:04:43 UTC
*** Bug 56834 has been marked as a duplicate of this bug. ***

Comment 7 Tim Waugh 2002-03-06 13:05:02 UTC
Hmm, this is causing problems.  lpdomatic's call to getopts doesn't understand
what's going on and complains.

The lpdomatic command-line ends up like this:

/usr/sbin/lpdomatic: called with arguments:

but lpdomatic's getopts call is expecting this format:


It's just the '-Z...' and '-J...' bits that we want, so I plan to just extract
those in the mf_postscript_wrapper like this:

        case $ARG in
                "--rerender-ps" )
                        RERENDER_PS="1" ;;
                "--mfomatic" )
                -Z* | -J* )
                        args="$args $ARG" ;;
                -* )    ;;
                * )
                        args="$args $ARG" ;;

Comment 8 Tim Waugh 2002-03-06 14:08:12 UTC
Fix applied in 0.3.72-1.

Note You need to log in before you can comment on or make changes to this bug.