Red Hat Bugzilla – Bug 101425
Printconf python scripts can't deal with a printing command that doesn't have a '.' in its filename
Last modified: 2007-04-18 12:56:29 EDT
Description of problem:
Our product, Codehost BrightQ, introduces a new alternative print command, and
uses the alternatives mechanism to cleanly install it on Redhat and other
However, starting with RH9, we get Python error messages on the console every
time the printing system init script is restarted (/etc/rc.d/init.d/cups start).
This seems to be caused by the naming convention for our command (pjm), while
the scripts expect something of the form lpr.<system>.
The scripts should handle this gracefully and not crash if there is no dot in
Version-Release number of selected component (if applicable):
Happens with 0.6.47-1
Introduce a new alternative printing command, using update-alternatives, and
restart the printing system through the init script.
Steps to Reproduce:
1. Define a new 'print' alternative with update-alternatives
2. Make the new alternative the current selection
3. Restart the printing system through the init script
Stopping cups: [ OK ]
Starting cups: Traceback (most recent call last):
File "/usr/sbin/printconf-backend", line 7, in ?
File "/usr/share/printconf/util/backend.py", line 48, in ?
which = cups_import.which_spooler ()
File "/usr/share/printconf/util/cups_import.py", line 191, in which_spooler
which = l.split ('.').strip ()
IndexError: list index out of range
[ OK ]
The which_spooler function in cups_import.py needs to first check for the
presence of the dot before splitting the string.
Well, redhat-config-printer only knows how to deal with LPRng and CUPS in
conjunction with foomatic.
In rawhide, redhat-config-printer will have cups as a requirement.
Well, yes, it's all fine and dandy, but this bug report was about an unnecessary
hard crash in your software, not a request for support of a printing system or a
new set of filters. Whether or not it knows how to deal with it, I don't think
it's ever acceptable for printconf to just completely bail and abort all
operations while the simple fix is a single line of Python code. If anything
else, error handling is a safe coding practice.
We found a way to work around this in our code, so it's not that much more of an
issue on our side, though the side effects with earlier versions of our software
are really annoying (printconf just crashes and doesn't finish doing what it is
supposed to do, like regenerating the printcap files).
Of course, the fix isn't necessarily a single line of python code: if the
spooler isn't cups, redhat-config-printer is out on a limb and has no idea how
to drive it.
I completely agree. However I still think it would be better to gracefully exit
with an error message in such a case (which is trivial to detect), instead of
the current catastrophic crash.