Joseph Kowalski wrote:
> John Leser wrote:
>> Joseph Kowalski wrote:
> ...
>> We're proposing a particular way of doing things with the idea that
>> future CLI tools will do the same thing unless they have a
>> substantial reason for not doing so. I think the word "guideline"
>> was used to avoid words like "requirement" which implies all sorts of
>> nasty process. Sorry if it caused confusion.
>
>
> You are proposing a different way of doing things that flys in the
> face of so many cases. There have been many cases given the following
> advice (perhaps in TCR form):
>
> "Don't parse complex output. If you need a specific value, provide
> an option to deliver the specific value"
>
And therein lies my sort of backhanded comment about XML. I don't
understand all the effort being put into making output from these tools
"parseable" from whatever scripting language du jour. It seems to me
that there are other possibly superior solutions:
1) Add switches to the commands to just query for the data you want
(possibly adding switches like -o that someone else mentioned, and
possibly adding new switches to indicate a "search key".) This probably
works well for some kind of simple data.
2) For data that is more complex, perhaps an XML format isn't that
bad of an idea, especially if coupled with the presence of a general
purpose tool to parse and extract XML. I think this sounds pretty
horrid, but the point here is, the format already exists, tools exist,
so why are we inventing a new format? "eval" can't be the rationale
here. (And, I'm sure if one doesn't already exist, Roland will figure
out how to make the XML parser a ksh93 builtin. :-)
3) Also for complex data --- um, why are we trying to parse it from
tools like awk and sh in the first place? I mean, if the main consumer
for this kind of data are things like GUI applications such as nwam, why
not write those applications in a real language, and provide access to
the data in a form that is "natural" to the language -- e.g. structured
C data, or hashes in Perl, and so forth? (We do have libdladm,
right?) This has the added benefit of separating the data meant to be
consumed by application developers from the data used by administrators,
and ultimately making the man pages that the admin has to read smaller
and hence simpler. :-)
-- Garrett
