lkml.org 
[lkml]   [1997]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: procfs problems
Date
Frank Sweetser writes ...
>
> While I agree that for programs, a non-human readable presentation with
> fixed offsets is generally more parsable (perl doesn't count here :),
> probably the single most useful function I've found for /proc is for
> finding out what the status of your machine is when things have gone
> down the tubes, often off of a root/boot floppy set. When you're dealing
> with that kind of a setup, it's certainly much nicer to just use 'cat'
> instead of a suite designed to parse some binary data. Perhaps make
> the textual proc a compile-time option, and then add a /dev/kmem type
> interface that presents a binary single-file version of the proc
> interface?

How much more complex is a /bin/proccat that (for example) changes null
terminated key:value pairs into text? E.g. the proc files would contain
something like:

"key1\0val1\0key2\0val2\0..."

which would translate to:

key1 : val1
key2 : val2
...

Support for hierarchical entries, simple tables, etc doesn't make it much
bigger. Anything can appear in a field (including ':'), and the binary
version is trivially machine readable. /bin/proccat is likely to succeed
whenever /bin/cat would, so it is usable when your system is hosed.

---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.070 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site