lshw -xml produces incorrect (but parsable) output

Bug #769622 reported by Steve Newcomb
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lshw (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: lshw

Example of buggy output:
<resource type="irq&quot; value=&quot;51" />

It's true that the above now parses as XML. It's not true that it's correct output! The output should be:

<resource type="irq" value="51" />

See exiz ticket #115 for a bug which is gone. Alas, there's now a different but similar bug in the xml output of lshw (at least in Ubuntu 10.10). I suspect the fix applied to the #115 bug created this new bug, reported above. I attempted to report the problem to exiz but their bug tracking stuff is broken, perhaps by Trac. It rejected my report as spam. So above is the report that exiz rejected.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: lshw 02.14-1build1
ProcVersionSignature: Ubuntu 2.6.35-28.50-generic 2.6.35.11
Uname: Linux 2.6.35-28-generic x86_64
Architecture: amd64
Date: Sat Apr 23 16:28:04 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate amd64 (20100928.1)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: lshw

Revision history for this message
Steve Newcomb (srn-coolheads) wrote :
Revision history for this message
Steve Newcomb (srn-coolheads) wrote :

I have also found a completely different bug in the xml output of a slightly more elaborate lshw invocation:

lshw -xml -class disk

The xml output of lshw is all <node> elements. When the lshw invocation is:

lshw -xml

that's fine, because the host machine's <node> is the container element for all the other <node>s. But when the output is restricted to '-class disk', only the disk <node>s appear, without any container element. In such a case, the xml parser (in my particular case, expat) sees the first <node> as the entire document, and all succeeding <node>s as unparseable "junk after document element".

So, when the output is restricted to a single class, there still needs to be some sort of container element. There are two obvious possible answers:

(1) Never exclude the host-machine node, so it's always the container element.

or

(2) Generate a bogus container element, such as <lshw> or <document> or something like that.

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

no longer saw &quot; in eoan. also in eoan, the node are contained in <list>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.