In spite of the truly astounding amount of commentary this case has
generated, the discussion does appear to be converging on a useful
pattern for utilities to follow.
John Plocher wrote:
> 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
I think this is a good pattern to follow, but it should be customized
for specific commands:
1. The -p option (for parseable output) is only needed if the command
normally produces unparseable output. If it's the default, there is no
need to have an option that is silently ignored.
2. For most commands, I don't think the -t option to specify the
delimiter is necessary or useful. The choice of delimiter is generally
made by picking a character unlikely to occur in the data (and thus need
escaping). Surely the author of the command is in the best position to
make this determination. Aside from general text processing utilities,
allowing the consumer to change the delimiter isn't that useful.
[Another nit: I think there may be equal or greater use of -d instead of
-t for this purpose in existing commands.]
3. I think Joe's suggestion to avoid parsing entirely by retrieving just
one field at a time makes a lot of sense. A command that accepts only a
single field name argument to -o should be an acceptable special case of
this pattern.
At this point, I think it would make sense to capture the guidance
above, including the special cases, as the pattern for future commands
to follow. It also makes sense to approve syntax for dladm that follows
this pattern, as I believe the current proposal does.
Scott
