Darren J Moffat wrote:
> Garrett D'Amore wrote:
>>
>> While there has been some conversation, and it seems like folks are
>> generally in favor of this proposal, I've not seen any actual +1s
>> from any voting ARC members. Can I hear one please?
>
> Seems reasonable to me as specified, but see below.
>
>> Also, on the question of "parseable" pfiles output, I like the idea,
>> but I think the answer is "not this case". As has been pointed out
>> already, I don't think the changes described for this case make the
>> output any more ambiguous than they already are.
>
> Agreed not this case, but I think the proposal of putting
> offset: after the file name does actually make it harder
> to parse the existing output of pfiles(1), since today you
> can assume that the filename is on a line of its own.
Concur with the concern... but...
>
> All the other non filename fields in the pfiles(1) output
> are on a different line to the filename. So I'd highly recommend
> that offset go on the same line as mode: or on its own line.
> If that is done then an offset of 0 should be printed for
> things that are seekable.
If you put it on the same line as the mode:, then you wind up having to
line wrap. This makes the content less usable for *human* consumers.
It seems like folks writing *software* should probably not be consuming
pfiles output, but possibly using procfs directly.
I think this is probably a case where the separate needs of programs and
humans lead to divergent design.
-- Garrett
