> For the choice of delimiter, if the "read" routines already handle
> the escape sequences AND you are generating all the output, you could
> as easily generate MAC addrs in an escaped form and the consuming
> shell wouldn't need to care. (yes, MAC addrs of the form xx\:yy\:zz
> would show up in the output stream, but (other than being ugly) would
> add no effective complexity to their use...)
That's a good point, especially since the output is intended only for
scripts (which won't be offended by the escapes), and using : is slightly
easier for scripts since IFS=: doesn't require any quoting, but IFS='|'
requires the surrounding single-quotes (as shown) to not be misparsed by
the shell. John (Leser): what do you think?
> Architectural "bigger than nit":
>
> The question of having a common "parsable format" across all of the
> various OpenSolaris utilities -vs- per utility and/or per-family
> quirks and gratuitous differences *IS* an architectural issue. IMHO,
> there should be utility code in the system that both generates AND
> parses a common format so everyone does not end up reinventing this
> wheel.
One of the benefits of having the format be easy for shells is that the
shell provides the parsing utility code -- as per my earlier example, this
really should be trivial. The only bit of complexity would be picking out
which items one was really interested in, which depends on what the
consumer is trying to do, and on what fields in that particular output
format form the unique "key"[1]. So I don't think there's much to
reinvent there.
As for the generation code: in my experience, this is harder than it seems
because (among other things) the APIs one would need depend on the way the
utility producing the output is structured -- many existing utilities are
built to print the data a cell at a time, whereas others print a row at a
time, and still others gather all the information first and then print a
table. That said, I have built some mostly-generic row-at-a-time routines
for ipmpstat that I'd be willing to generalize further and package up into
a reuseable API if folks are interested. But it's not easy to create a
simple API that completely separates the parsing machinery from the data
collection, so I'd like to get some more experience with it and later run
it as a follow-on case.
[1] For instance, show-link has a unique key of LINK, whereas
show-linkprop requires LINK and PROPERTY to form a unique key.
--
meem
