Red Hat Bugzilla – Bug 145904
Unjustified assumption in py config scripts
Last modified: 2007-11-30 17:10:58 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
I'm using the most recient FC3 release (2.6.10-1.741_FC3), and noticed
that the "Printer Configuration" applet would not display.
Starting it by hand revealed the problem in two of the python scripts
In both queueTree.py and cups_import.py, the assumption is made that
there is an active spooler, so the call to os.popoen ('LANG=C
/usr/sbin/alternatives --display-print') returns a valid file pointer.
I "fixed" the problem by modifying the code to initalize "which" to ""
so the functions would have something to return when no printer list
was returned and the "for" loop was executed 0 times.
I was then able to (re)configure my printer.
(Um, I have no idea why the spooler disappeared.)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Attempt to open the "Printer Configuration" applet when no printer
is properly configured
Actual Results: Applet was not displayed (actually, blinked up and
Expected Results: Applet should have been displayed
See discription for fix
Well, it's not the case that "no printer is properly configured" is the trigger
for this -- it's that cups is not installed properly. The *real* problem is
that your spooler disappeared. :-)
Any idea why that happened?
No really. I'd been trying both Gnome annd KDE as desktops, and (I believe) KDE
messes with the printer set-up. Since the "problem" I have upgraded CUPS at
least once, and have had no further problem. But I don't know why the problem
happened in the first place. (Printing had been working fine for several weeks
[i.e., ever since I'd installed Fedora], and then just "stopped." That's why I
was trying to bring up the printer configuration application to try to fix the
problem. In fact, after I patched and ran the Python code, the problem was fixed.)
In other words, I needed to run the code to configure things properly, but the
code couldn't be run because thing weren't properly configured. This is refered
to as "Catch 22."
In any case, I would contend that "good programing practices" mandates that no
assumption that a function call will not return a error code (when the function
specified that it might do so) should be made. By checking that the list of
spoolers was not empty, you would be able to pop a warning that CUPS was not
properly configured rather than just failing to execute. And then the
configuration could be fixed, as it was when I got the code to run.
The cups_import which_spooler() function is no longer used, so this particular
issue should no longer be a problem.
*** Bug 155171 has been marked as a duplicate of this bug. ***