> In article <Pine.LNX.3.91.981024070909.7978B-100000@mhw.ULib.IUPUI.Edu> Mark Wood writes:
> >[...] Perhaps much more important than
> >endianness or punctuation is once and for all settling the question of
> >whether /proc is for humans or for programs.
> ^^^^^^ ^^^^^^^^
>
> That is a false dichotomy. /proc is aimed at scripts (a type
> of program) and, to a lesser degree, system administrators (a type of
> human) and programmers.
I have not seen any agreement on this point. Look at the lossage that
pops up regularly when some well-meaning individual patches something to
rearrange columns or admust punctuation or whatever, to make it "more
readable". That person obviously believes that /proc is for humans, not
programs. No one would do such a thing if he expected a program to read
that branch of /proc.
Again, there are parts of /proc that are so cryptic that one cannot help
but write scripts to provide the decorations that make it readable. No
one would use such undifferentiated formatting if he expected a human to
read that branch of /proc.
There is no agreement.
> /proc enables programs that may be as simple shell scripts to
> access all kinds of obscure kernel data in a concise, obvious and
> easily debuggable style without necessarily needing a layer of C
> library calls and helper programs, using the strategy of putting
> everything in text formats designed to be as easy as possible to parse
> by programs and viewed by system administrators.
Text format is almost never "as easy as possible to parse by programs."
If the item in question is an integer, I want an int, not a string that
could possibly be interpreted as representing the value of an int.
> The rise of "scripting"
> languages shows that this approach ends up being beneficial to a wider
> range of programs and users than one would initially think, because it
> enables more or better software to be produced from a given amount of
> effort, or enables software to be produced faster.
I am not convinced that your observations require your conclusions, but
neither am I prepared to deny your conclusions.
> /proc is not all things to all people. There are many cases
> where some sort of direct system call interface should be offered
> instead of or in addition to a /proc interface, due to the complexity
> of data or throughput issues.
The problem is that /proc is not all things to all people, but we've
tried to make it be so anyway.
> As this logic applies to data formats, I think the data
> formats exported by /proc should be as close as possible to the
> command line arguments or external data formats used by related
> programs. So, /proc/mounts looks like /etc/mtab, internet addresses
> should be in dotted quad notation, etc.
Here I agree with your conclusions but not (necessarily) with your
premises. :-)
> I think most people would agree that the simplest and most
> maintaintable formats for shell scripts and similar programs are
> locale independent, byte order independent, arbitrary precision,
> trivially parsible text with one record per line, all lines having the
> same format, except for possibly one or more well defined preamble
> lines that are trivial to skip.
Well, I would. But what about programs that aren't shell scripts or similar?
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Some things are not improved when made "graphical". Imagine how crude Kilmer's "Trees" would be if reduced to comic-book form.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/