🚀 go-pugleaf

On 31 Jul 92 00:08:22 GMT,
tchrist@convex.COM (Tom Christiansen) said:

Tom> Boyd is dead right here.  I am constantly incensed by massively
Tom> UNIX-ignorant programmers who inflict brain-damaged software on 
Tom> the rest of us who actually try to use it.  You know, the ones who
Tom> simply don't have any concept of how filters should work, what 
Tom> stderr is for, how to parse options, what the exit status 
Tom> should be used for, or who only supply an interactive interface.

Tom> Expected output should go out to stdout.  Exceptional output related
Tom> to diagnostics or other error messages should go out stderr.  

This is definitely correct, but let me offer an explanation as to why
this is a `good thing'. Actually, it's simple. I want to route
`standard' output to a filter or to another file put keep errors routed
to my terminal so I can see what is going on. Alternatives, I may log
the errors from a command sequence for examination later.

There are a couple of concepts that help make Unix flexible and
useful. One is the ability to compose functions (pipes). Associated with
that is the split of information into stdout and stderr. This allows the
construction of filters and the creation of log files easily.

Exit status is a pet peeve of mine. There are large numbers of programs
in common use that do NOT set the error status at all. I suspect that
the code just drops through main or uses a return without a value. I
remember working with the Whitesmith's C compiler many years ago. It did
set its exit status consistently. Unfortunately it was 180 degrees
opposed to the standard in Unix. It used 1 for success and 0 for
failure. It made for some very interesting makefiles. We took the
expedient way out -- ignored the exit status from the compiler. We never
really knew if the make succeeded or not.

It really isn't a matter of flexibility but rather one of consistency.

Thanks to Boyd and Tom to pointing this out.

Ed
--
Ed Hirgelt			esh@tss.com
Direct Interfaces Corporation
San Jose, Ca.