If you'll specify how you want it to look / work I'll (possibly) attempt to provide a patch.
`s6-svstat --json` is my initial bid. I'll try to match the nosh output as closely as is reasonable. On Thu, Sep 24, 2015 at 4:27 AM, Laurent Bercot <[email protected] > wrote: > On 24/09/2015 12:56, e-mail j.deboynepollard-newsgroups wrote: > >> Unless some daemontools-family >> developer goes and does something wrongheaded like breaking compatibility >> > > I did. There were good reasons for it: the way the bits are arranged in > the legacy daemontools status format is suboptimal, and getting the useful > information out of it requires a little extra work - and I got confused > a few times by the meaning of the bits. > > The status file was never an "official" interface, and the tools that > parse it are actually looking under the hood and breaking abstraction > layers. I'm surprised that you, of all people, advocate this procedure: > this is clearly bad programming practice. > > > There is something wrong with processing the output of svstat, and you are >> right to be leery of doing so. The daemontools manual explicitly states >> that it >> is human readable, rather than machine-readable. And there are variations >> in the >> human-readable forms, which are fine for humans but no good for programs. >> > > Still, svstat is the only "official" interface, so for now it's the only > safe way to proceed. I agree that it is inconvenient, and that daemontools > should have provided a tool to get machine-readable status information; > but in the absence of such a tool, svstat is the entry point and should > be used as such. > > s6 provides a C API to read status: s6_svstatus_read(). The command-line > interface to it is s6-svstat. It's currently lacking options to output > machine-readable data; I plan to add that functionality, but in the > meantime, it *is* the interface. > > -- > Laurent > >
