On Fri, Oct 17, 2008 at 09:41:41AM -0700, Antonello Cruz wrote: > James Carlson wrote: > > Antonello Cruz writes: > >> You can get the ctid from svcs -l <fmri> and the processes member from > >> ctstat -vi <ctid> and then process the output of ctstat. > >> The downside of this approach is that I don't think either output, 'svcs > >> -l' or 'ctstat -iv' are stable so you can rest assured your script will > >> not break. > > > > 'svcs -Ho CTID <fmri>' should be expected to produce stable output, so > > you ought to be able to do this to get the PIDs in a service: > Right, but that's not what's in svcs(1). > It says: > "Screen output is Uncommitted. The invocation is Committed." > > Just to make my position clear. I am all in favor of doing the output of > -o col[,col]... stable. I just saying the man page says it is uncommitted. > > And I also believe ctstat should have a stable output for all its fields.
I think a utility that like svcs(1), zfs(1M), ps(1) that has options for removing the header from the output and for selecting specific fields should have that output considered stable. Particularly in the case of svcs and zfs it's hard to conclude that the intended stability was otherwise. The zfs(1M) manpage doesn't specify the stability of its output, but it's clear that without -H the output cannot be stable. For example, if the output of zfs list ... is empty then you get a localized message printed on stdout to that effect, whereas if the the output of zfs list -H ... is empty then you get EOF on stdout -- it would not be reasonable to consider the former stable but the latter not! Similarly for svcs(1). I'm pretty sure that an update to the Greenline case stating this would be accepted, that the manpage update should be done, that this is really not controversial. So much so that I think stable -H output is strongly implied; the ARC surely would reject a backwards incompatible change to it! Nico --
