This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 58980 - lpr -Z options do not work
lpr -Z options do not work
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: printconf (Show other bugs)
7.2
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
: 56834 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-28 16:12 EST by Bill Seligman
Modified: 2008-05-01 11:38 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Bill Seligman 2002-01-28 16:12:03 EST
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:

                  LPRng-3.7.4-28
                  Omni-0.5.0-4
                  Omni-foomatic-0.5.0-4
                  printconf-0.3.52-1
                  printconf-gui-0.3.52-1

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:

                  hp4550:\
                          :ml=0:\
                          :mx=0:\
                          :sd=/var/spool/lpd/hp4550:\
                          :af=/var/spool/lpd/hp4550/hp4550.acct:\
                          :sh:\
                          :rm=hp4550.someplace.somedomain.here:\
                          :rp=lp:\
                          :lpd_bounce=true:\
                          :if=/usr/share/printconf/util/mf_wrapper:

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
it.

Any ideas?



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


How reproducible:
Always

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)
3.
	

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

Expected Results:  The print options should take effect.

Additional info:
Comment 1 Bill Seligman 2002-02-05 12:35:50 EST
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
/usr/share/printconf/util/mf_wrapper;

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
/usr/share/printconf/util/mf_postscript_wrapper;

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
example.  

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
work.

> 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 @@
 MF_RULE_DIR='/usr/share/printconf/mf_rules'
 MF_RULES=$MF_RULE_DIR/mf[[:digit:]][[:digit:]]-*
 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
 RETVAL=$?

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

 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 =
'/usr/share/printconf/util/mf_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
$gs_driver-$printer_id.foo";
+       $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?
#dnl
        $pcl_filter = 'cat';
Comment 2 Tim Waugh 2002-02-05 13:33:10 EST
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 13:43:02 EST
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 13:49:54 EST
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 03:54:43 EST
Fix built as printconf-0.3.68-1.
Comment 6 Tim Waugh 2002-03-06 07:04:43 EST
*** Bug 56834 has been marked as a duplicate of this bug. ***
Comment 7 Tim Waugh 2002-03-06 08:05:02 EST
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:
'--lprng','-Aroot@localhost+330','-CA','-D2002-03-06-12:32:12.224','-Ff','-Hlocalhost.localdomain','-J/usr/share/printconf/tests/testpage-a4.ps','-N/usr/share/printconf/tests/testpage-a4.ps','-Ptest','-Qtest','-a/var/spool/lpd/test/test.acct','-b18255','-d/var/spool/lpd/test','-edfA330localhost.localdomain','-f/usr/share/printconf/tests/testpage-a4.ps','-hlocalhost.localdomain','-j330','-kcfA330localhost.localdomain','-l66','-nroot','-sstatus','-t2002-03-06-12:32:12.000','-w80','-x0','-y0','/var/spool/lpd/test/test.acct','bj200-58720.foo'

but lpdomatic's getopts call is expecting this format:

   getopts("cw:l:i:n:j:h:z:o:Z:J:");

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" )
                        MFOMATIC='1';;
                -Z* | -J* )
                        args="$args $ARG" ;;
                -* )    ;;
                * )
                        args="$args $ARG" ;;
Comment 8 Tim Waugh 2002-03-06 09:08:12 EST
Fix applied in 0.3.72-1.

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