[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe260c38cf7e416288449691bb9cb5dd@AcuMS.aculab.com>
Date: Sat, 31 Dec 2022 16:31:30 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Shawn Webb' <shawn.webb@...denedbsd.org>,
"oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
CC: Alejandro Colomar <alx.manpages@...il.com>,
Michael Kerrisk <mtk.manpages@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>
Subject: RE: [oss-security] [patch] proc.5: tell how to parse /proc/*/stat
correctly
From: Shawn Webb
> Sent: 28 December 2022 15:25
>
> On Tue, Dec 27, 2022 at 04:44:49PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > Dominique Martinet writes:
> >
> > > But, really, I just don't see how this can practically be said to be parsable...
> >
> > In its current form it never will be. The solution is to place
> > this variable-length field last. Then you can "cut -d ' ' -f 51-"
> > to get the command+args part (assuming I counted all those fields
> > correctly ...)
> >
> > Of course, this breaks backwards compatability.
>
> It would also break forwards compatibility in the case new fields
> needed to be added.
>
> The only solution would be a libxo-style feature wherein a
> machine-parseable format is exposed by virtue of a file extension.
>
> Examples:
>
> 1. /proc/pid/stats.json
> 2. /proc/pid/stats.xml
> 3. /proc/pid/stats.yaml_shouldnt_be_a_thing
None of those are of any real use if you are trying to parse the
data in something like a shell script.
Multiple lines formatted as "tag:value" are probably the best bet.
Provided something sane is done with embedded \n (and maybe \r).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists