>> particular, the /proc interface was changed, thus breaking compatibility
>> with programs which expected to be able to parse the output of /proc
>> files. That's what caused the flames, not the changes in the comments,
>> by and large.
>
> Thanks for the information. Incidently, I continue to be nonplussed by
> the difficulties people have writing simple parsers, and therefore
> mystified by the chorus of complaints that arise when a tool breaks
> because of a minor change in the /proc interface. In the first place the
> interface should have been documented, but if it isn't the tool writer
> should be prepared to read liberally ("read liberally, write
> conservatively"). Parsers are very very very easy to write. At worst
> one can fall back to yacc (yecch ..). There is no excuse for whining
> when the tool breaks: one should look at the change; if it is minor,
> the tool should be modified to be more liberal, and thanks; if it is
> major, the interface author should be chastized.
So I must put significant work into a parser that will understand
whatever crazy changes might happen (an AI parser), and get a
result that is very slow. No thanks. Dumb parsing is slow enough.
An example of good formatting would be /proc/1/stat. Few people
are tempted to screw with it, since it is mostly just numbers.
The pretty files are harder to parse and attract reformatting.
>> although I personally consider spelling fixes to be a waste of
>> everybody's time. Obviously other people have different ideas what they
>
> Wurl, as alen poynted owt, speling misteks ar anoying to thows of us
> who kan spel beter, and giv en unprofesionel impresion.
Spelling fixes are good. Grammar fixes are mostly useless.
ASCII is ASCIIZ in the C language, so the distinction is useless.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu