Peter van Gemert writes: > I'm less thrilled by your decision to separate method from start|stop with a > space. It makes it harder to parse the output of svcs through awk or perl. Mo > st lines in svcs -l start with one keyword and the rest of the line consists > of the value of the keyword: > e.g. > fmri svc:/network/ssh:default > contract_id 121 > state_time Thu Sep 20 11:14:35 2007 > > Even though the dependencies also use a three columns output I think it would > be easier (parsable) when the separator would be a _ (underscore) > > like: > method_inetd_start /usr/sbin/in.telnetd > method_start /lib/svc/method/smtp-sendmail start
But this doesn't resolve the problem I raised in my original mail. I can't put it into the (first) fixed width field as method name is variable length. You'd be sacrificing the whitespace between the token and the fixed width field in your example, which sacrifices human parseability by for machine parseability. Ignoring that for a second, I think the only case in which your output is more machine parsable than mine is when you know the name of the method you're looking for, and you want *only* its value. But, in that case, this invocation will always be more concise *and* precise than either of our formats for machine-parseability: $ svcprop -p stop/exec sendmail The value of the svcs -l output from a machine-parseability point of view is really when you don't know the method names and you want an exhaustive list. For that case, I think our output formats are equivalent. Obviously, there's the human-parsed case too, which I'd consider to be the primary design center. (And thus, my first concern above.) I considered this output as well, but am not terribly fond of the ':' separator here, so had retreated to a space. method inetd_start:/usr/sbin/in.telnetd method start:/lib/svc/method/smtp-sendmail start liane
