Menno Lageman writes:
> Liane Praza wrote:
> >
> > I also decided to leave the method name out of the fixed width field,
> > as method name length is variable. I think the space separation
> > between method name and the actual method is a reasonable choice, but
> > am happy to hear feedback on anything that increases human usability
> > without sacrificing output format or potential machine parseability.
> >
>
> I think leaving the method name out of the fixed width field is a good
> choice. To enhance human usability, it might be better if the method
> name and its value were separated by a tab instead of a single space:
Tab is dangerous because it seems like a convenient way to line
things up, but looks messy if one method name crosses the tab boundary.
But, that's fine -- I can easily fix the field width and do something
which looks like tabs but is actually spaces. It's more risk of
overuninng the line length, but I think that's OK.
So, here's a list of all the formats proposed, so that folks can see
the human readability factors. The example is contrived, but was chosen
to show a combination of salient details.
Liane's original:
enabled false
state disabled
[...]
method inetd_start /usr/sbin/in.telnetd
method start /lib/svc/method/smtp-sendmail start
Peter's:
enabled false
state disabled
[...]
method_inetd_start inetd_start:/usr/sbin/in.telnetd
method_start /lib/svc/method/smtp-sendmail start
Liane's ':' revision:
enabled false
state disabled
[...]
method inetd_start:/usr/sbin/in.telnetd
method start:/lib/svc/method/smtp-sendmail start
Menno's:
enabled false
state disabled
[...]
method inetd_start /usr/sbin/in.telnetd
method start /lib/svc/method/smtp-sendmail start
For human readability, I like Menno's the best. All formats proposed
are machine parseable, with varying degrees of simplicity depending
on the toolkit you use for parsing ([n]awk, sed, grep, cut, perl, etc.).
Thus, it seems valuable to engineer for human readability, and keep
an eye out to make the machine parsing reasonable.
If there's a use case in which Menno's is *not* machine parseable
I'll reconsider, but I'm going to code up his version and post an
updated webrev.
liane
