Messages in this thread | | | From | (Tim Hollebeek) | Subject | Re: procfs problems | Date | Wed, 30 Apr 1997 18:26:00 -0400 (EDT) |
| |
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!)
| |