Red Hat Bugzilla – Bug 28889
printconf-gui will not take printer names where a number is the first character
Last modified: 2008-05-01 11:37:59 EDT
printconf-gui. make a new printer name it 12345 - select anything you want for the other printer settings. press ok. It will fail with this error information on the console. ** CRITICAL **: file alchemist.c: line 3242 (AdmList_addChild): assertion `_adm_valid_name(name)' failed. Traceback (innermost last): File "/usr/lib/python1.5/site-packages/libglade.py", line 28, in __call__ ret = apply(self.func, a) File "/usr/sbin/printconf-gui", line 880, in handle_new_button queue = new_queue(name) File "/usr/sbin/printconf-gui", line 142, in new_queue queue = dynamic_ctx.getDataByPath('/' + namespace + '/print_queues').addChild(Alchemist.Data.ADM_TYPE_LIST, name) File "/usr/lib/python1.5/site-packages/Alchemist.py", line 134, in addChild name)) Alchemist.ListError: addChild failed Additionally printconf-gui should be accessible from the gnome system menu.
We (Red Hat) should really try to resolve this before next release.
oops. Yeah, the underlying encoding wont allow this. I can't change this, but I can throw a check into printconf-gui.
why can't you change it? I know lprng supports it - is it the xml backend that doesn't support it or the xml->printcap processor that can't handle it. Moreover why is a string starting with a number as a name a hard thing to deal with? This seems like an odd arbitrary limitation. I'm just curious what the problem here is.
yes it is arbitrary, yes I am unhappy about it. This is the reason: It is not valid to start an XML element with an integer. At one point in the design process, a conflict in encoding arrose, and the majority decided to encode the name of an alchemist data object as the name of the XML element that encoded it, thus limiting valid object names to valid XML names. we further limited it to the pattern /[-_a-zA-Z][-_a-zA-Z0-9]?/, because we had to do validation on some pattern. I chose to store printer names as the name of the parent list for the printer, because this gives me access to tree merge collides, which is the whole point of the alchemist. So, you can't do it because I want the system to be able to cleanly merge configurations from multiple sources at the alchemist layer. (Think a departmental printer config with local machine overrides.) The code is all there, but I need a secure network client to feel safe about exposing the configuration. The check is in, this is as fixed as it's gonna get.
> Additionally printconf-gui should be accessible from the gnome system menu. Is this going to be added? In RH 6.x, printtool was available from control- panel. In RH 7.1 (7.0 too?), a user has to know to type printconf-gui from a console window in X.