lshw -xml produces incorrect (but parsable) output
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| lshw (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: lshw
Example of buggy output:
<resource type="irq" value="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
ProcVersionSign
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
| Steve Newcomb (srn-coolheads) wrote | #1 |
| Steve Newcomb (srn-coolheads) wrote | #2 |
| Yuan-Chen Cheng (ycheng-twn) wrote | #3 |
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.