Messages in this thread | | | Date | Thu, 17 Apr 1997 02:35:33 +0300 (EET DST) | From | Mikko Ala-Fossi <> | Subject | Re: procfs problems |
| |
On Wed, 16 Apr 1997, Richard B. Johnson wrote:
> On 16 Apr 1997, Stefan Monnier wrote:
> > Evan Jeffrey <ejeffrey@eliot82.wustl.edu> writes: > > > > /proc -> /system/proc > > > > /dev/fd -> /system/fd > > > > /dev/scd0 -> /system/devices/scsi0/target6/lun0 > > > People are going to scream bloody murder about that. It breaks a lot of > > > stuff. OTOH, whatever we do to /proc is going to break some stuff. > [SNIPPED] [SNIPPED lot of strange rules]
> My proposal would change this to:
> Ignore the fact that this editor will put in a line-feed after > every line of text.
> processor cpu model vendor_id stepping fdiv_bug hlt_bug fpu > fpu_exception cpuid wp flags bogomips > 1 > 586 > Pentium 75+ > GenuineIntel > 12 > no > no > yes > yes > yes > yes > fpu vme de pse tsc msr mce cx8 apic > 66.36
> Now, this isn't pretty. But it parses easily. Even if you do > everything without sscanf() and friends, we readily have the > following information after the first file read.
> o The number of data elements. (The number of characters > with the value of 0x20 or below).
> o The names of the data elements and any to be ignored or > skipped.
It is not that much easier to parse this than it is to parse current /proc/cpuinfo. Actually I find it easier to parse present cpuinfo format than this. It is actually very easy and fast to parse
procfile := procline procfile | procline procline := field whitespace ':' whitespace value '\n' whitespace := ' ' whitespace | tab whitespace | E
so there not really sense having less human readable format. Current /proc/cpuinfo is also easy to parse with grep and cut in your shell-scripts.
| |