Bug 101425 - Printconf python scripts can't deal with a printing command that doesn't have a '.' in its filename
Printconf python scripts can't deal with a printing command that doesn't have...
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-printer (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-31 17:37 EDT by Stephane Peter
Modified: 2007-04-18 12:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-08-29 10:09:16 EDT
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 Stephane Peter 2003-07-31 17:37:36 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
distributions.
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
the filename.

Version-Release number of selected component (if applicable):
Happens with 0.6.47-1

How reproducible:
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
    
Actual results:
Stopping cups:                                             [  OK  ]
Starting cups: Traceback (most recent call last):
  File "/usr/sbin/printconf-backend", line 7, in ?
    import backend
  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 ('.')[1].strip ()
IndexError: list index out of range
                                                           [  OK  ]

Expected results:
No error.

Additional info:
The which_spooler function in cups_import.py needs to first check for the
presence of the dot before splitting the string.
Comment 1 Tim Waugh 2003-08-29 10:09:16 EDT
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.
Comment 2 Stephane Peter 2003-08-29 14:27:45 EDT
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).
Comment 3 Tim Waugh 2003-08-29 16:43:00 EDT
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.
Comment 4 Stephane Peter 2003-08-29 16:55:45 EDT
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.

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