what is the best way to determine system OS?

[Cameron Laird]

In article <868y37osc7.fsf at guru.mired.org>, Mike Meyer  <mwm at mired.org> wrote:
			.
			.
			.
>Anyway, checking the system name is the wrong way to build portable
>programs. For one thing, as you've discovered, new systems won't work
>properly. For another, upgrades to existing systems may break things
>as well.
>
>What you should do instead is check on how to use the features you
>want. If you watch a typical autoconf script, you'll see it groveling
>through libraries, include files, and various directories looking for
>subroutines, defines and commands. That's the idea, but without
>knowing which features you're looking for, I can't say how you would
>check for them.
>
>This takes more time to write, but results in more robust code. For
>instance, if some distribution changes one of the features to mimic a
>"better" distribution that you already support, instead of your script
>breaking, it'll just work. This is much better than having to teach
>your script how to distinguish between versions of distributions.
			.
			.
			.
Not for me.

Well, not absolutely.  I have a load of respect for you, Mike, and there 
certainly are amazing edifices built on autoconf.  Also, I think it's an
important part of our engineering to understand the principle of groveling
around interrogating capabilities; among other things, it's good practice
for duck typing and idiomatic Python exception style.  I'm very
uncomfortable, though, with an assertion that reliance on a fixed table of 
attributes is always wrong.  

Briefly, use of autoconf is FAR from a guarantee that everything works
right when starting with a new flavor.