> 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.