Darren Reed wrote:
> To bring this back to where it started, the issues are (for PSARC):
> - given that there will be future work that wants to generate
> parsable output, do we need an opinion written up (for this case)
> to serve as the notice of our decision about it or is it sufficient
> to just cite this case?
No opinion should be needed - though a best practice (written by Joe
or Garrett or Nico or you or...) that summarizes this into something
reusable would be good.
Unlike Joe, I do not believe this is a one-off - we need structure
and consistency in this area, and this case (like zoneadm) presents
a reasonable way to provide it *if*, in fact, the project team can
solve the escape sequence parsing problem).
To me, that structure is:
We (the ARC, Sun,...) do not want every utility to do
one-off parsable output formats if we can help it - or
to use different CLI utterances to obtain it. We want
the output to be easily usable in the places where we
expect it to be commonly used - shells, scripting languages,
etc. And we don't need to handle every conceivable future
possibility as part of this case.
A spec that would work for me would say simply
use
command -t ':' -p -o xx,yy,zz
to get tabular, ':' delimited and properly escaped output
Here are examples of how to use this output:
ksh93: ...
perl: ....
fortran: ... :-) ...
> - if we're going to use this case as the foundation for all future
> cases that are presenting output from commands, such as these,
> that is meant to be parsable, do we:
> 1) decide that we insist that commands use -o/-p unless history
> prevents it? (i.e. new commands *MUST* use this combination)
If new commands choose to provide parsable output, the CLIP
guidelines strongly suggest use of a common CLI term. "-p" seems
to be the one we have defacto standardized upon.
Same for "-o aaa,bbb,ccc". And ":" as a separator.
Wishing that we didn't have to parse command output so we wouldn't
have to address this issue is IMO naive. The fact remains that
it is common, useful and expedient to provide this type of data
in tabular multiline form. If it turns out that it isn't easily
parsable in shell, then we'll all just use perl or whatever - and
not lose any sleep over it. Getting access to the data is the key
enabler here - its exact format is secondary - if I can't get the
data in the first place, it doesn't matter what format it isn't in.
A revised spec would be good.
-John
