GoogleCodeExporter
commented
9 years ago Is it possible? Yes. Is it a monstrously huge amount of work? Yes. Will I do
it? No, since it would require rewriting more than 10k lines of code and logic
to handle a totally abstracted output format, instead of the one it has now.
Will I accept a patch that is well structured and not damaging to other things
in inxi to do that? Yes, if it's well done. Is it conceptually possible to do
it? Probably, but very very hard.
Since inxi at its core is printing lines, and generating those lines via
functions per data type, there's no clean or easy way to do that type of
feature, it's not impossible, but it's close. That is, nothing in inxi 'knows'
that any one line contains data identifiers, like: ID: vs the data, like:
/dev/hda1, all inxi 'knows' is that a line is greater or less than x
characters, which then lets it determine how long to make each line vs the
display width. It knows nothing about the contents of those character strings,
just that they have a count of characters.
Since however the output of inxi is predictable, in my opinion, the best way to
generate such xml type data files is to write a parser for inxi output, and use
the -c 0 option to turn off all color codes from output, then do whatever you
want with the data.
I'd say on a technical level, it's radically more simple to write a parser for
inxi output than to make inxi output be in variable data formats.
Writing a parser in a sense would be relatively trivial though it would be a
lot of work too since you have to handle all the data per item, but it's
nothing perl or bash+sed can't handle, or any other language that handles
regular expressions well, since the field names are known, and you can add in
custom separators to make it even easier to do.
But internally in inxi, no, that's incredibly hard, and I can't see any real
way to do it as inxi is designed and implemented at this point. A parser, yes,
that's easy, you know, basic stuff, take line: CPU: read until next primary
type, and then rewrite those to whatever format you want, a lot of work given
how many types inxi has, but it's doable by someone, not me since it scratches
no itch I have and fills no need I personally have. Anyone else is free to do
it though.
Also worth noting is that technically, one reason inxi actually works in an
acceptable time frame compared to other tools is that it actually does each
line line by line, ie, it does all the research and data collection per line,
then prints that line, then moves to the next line, and has nothing in memory
at all about what it just did, so there's nothing in it that can take the
overall output and say, ok, let's do something different with this.
I'm going to leave this as status 'new' not accepted, or "won't fix", because
it is something that someone out there might do, for example, someone could
write something that stores all the inxi output into a variable, not printing
it out, then runs it through a parser that then creates the desired data format
output, for example.
inxi with logging turned on, for example, creates in the .inxi directory stuff
like this, but in default mode, inxi writes nothing at all to the system, and
with logging, it only writes logs of what it found in its data collection and
print functions.
Hopefully this is clear. The best way to handle this is to, in my opinioni,
either run inxi, save output minus color codes, to a variable or temp file,
then parse that output, it would be easier to do I think than any other method.
That's the kind of thing I'd do if someone paid me to do it, because it's not
particularly interesting to do, but it's not hard, just very tedious, ie, it's
work.
Like: Read line starting with CPU:, then insert all data detected into xml
tags, or json, including handling error outpus, which can and often does
terminate various line data types/value pairs, and instead just prints out a
single error string. I would guess that such a parser could be done in about
200 to 500 lines of code, give or take, but I wouldn't want to get stuck
mainaining it, since every inxi change would require a corresponding parser
change.
In general I worry about inxi being able to give users the data in a nice,
readable, user friendly format, unlike most sys info type cli tools, but what
end users do with inxi's data is in my opinion basically up to them.
But I never reject ideas in general, for example, the huge rewrite to do line
widths more flexibly was a really old user request that took a really big
amount of work to do, but I left the issue open for years until I felt like
doing it, but that was more an end user usability thing than data format, and
usability issues I tend to put up fairly high, ie, can you read the output in
various size displays? But even that is not fully done, and is very hard to do.Original comment by inxi-...@techpatterns.com on 6 Aug 2014 at 4:56
- Added labels: Type-Enhancement, Priority-Low
- Removed labels: Type-Defect, Priority-Medium
Original issue reported on code.google.com by
ioan...@stoilis.gron 6 Aug 2014 at 3:54