what is the best way to determine system OS?

[googleboy]

Hi there.

I am writing a little app tha tI would like to make cross-platform
(debian, RH, Fedora, Solaris, AIX, etc)

Originally I decided to check what uname returned, as I didn't think it
mattered beyond the detail of Linux or SunOS etc.

Recently I have learned that FC3 breaks my script, so I need to be
able to determine not simply "Linux" but to know exactly what unix the
script is being run on.

What is the best way to determine this?

Thanks!

googleboy

 

[Philippe C. Martin]

How about popen of 'uname -r' ?

Regards,

Philippe

 

[Robert Kern]

Hi there.

I am writing a little app tha tI would like to make cross-platform
(debian, RH, Fedora, Solaris, AIX, etc)

Originally I decided to check what uname returned, as I didn't think it
mattered beyond the detail of Linux or SunOS etc.

Recently I have learned that FC3 breaks my script, so I need to be
able to determine not simply "Linux" but to know exactly what unix the
script is being run on.

What is the best way to determine this?

Look at the platform module.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Mike Meyer]

Hi there.

I am writing a little app tha tI would like to make cross-platform
(debian, RH, Fedora, Solaris, AIX, etc)

Originally I decided to check what uname returned, as I didn't think it
mattered beyond the detail of Linux or SunOS etc.

Recently I have learned that FC3 breaks my script, so I need to be
able to determine not simply "Linux" but to know exactly what unix the
script is being run on.

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.

<mike

 

[Fredrik Lundh]

I am writing a little app tha tI would like to make cross-platform
(debian, RH, Fedora, Solaris, AIX, etc)

Originally I decided to check what uname returned, as I didn't think it
mattered beyond the detail of Linux or SunOS etc.

Recently I have learned that FC3 breaks my script, so I need to be
able to determine not simply "Linux" but to know exactly what unix the
script is being run on.

What is the best way to determine this?

start here:

if that doesn't help, something like this could work:

(with proper use of try/except, of course)

on the other hand, it might be better to figure out why FC3 breaks your
script, and check for (missing/alternative) features instead of checking for
the exact OS version.

</F>

 

[Sion Arrowsmith]

How about popen of 'uname -r' ?

os.uname()[2] is probably a better way (ie it doesn't spawning
another process) of getting this information. I don't think it
will help the original poster though (depending on *what* it is
about FC3 which is breaking things) since it only provides the
kernel version.

 

[Cameron Laird]

.
.
.

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.

 

[Philippe C. Martin]

Well,

At least I discovered os.uname

Thanks,

Philippe

How about popen of 'uname -r' ?

os.uname()[2] is probably a better way (ie it doesn't spawning
another process) of getting this information. I don't think it
will help the original poster though (depending on *what* it is
about FC3 which is breaking things) since it only provides the
kernel version.

 

[Mike Meyer]

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.

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

You're right - it's not a guarantee that everything works
right. Nothing is perfect. You may run into something that you haven't
dealt with before. Or you may run into a file that you're using as an
indicator that contains information in a totally different format than
you expect. Both of those will break both technics. Checking for
features just gives you the possibility of success on a new
platform. You don't have that if you check for platform name.

Autoconf does things the way it does for a reason. Back before
autoconf (when dinosaurs walked the earth, etc.) people made systems
portable in a variety of ad hoc ways. Those that checked for
particular features tended to be more portable/robust than those that
checked for system name and tweaked everything depending on that. They
were also easier to port to new platforms, as the first step in the
porting process - figuring out what features the platform didn't
provide - was already done.

<mike

 

[googleboy]

Thanks for the edifying responses. I will try out these things and
figure out if I have enough to solve my problem.

What this script does is use take the output of vmstat to report idle
cpu cycles (or memory stuff, etc.) over a period specified by a
parameter, all the better to be a plugin for a monitoring service.

Basically it parses the output of the command, runs through a whole
bunch of regex to discard everything not required and then reports the
info. Everything I had checked out that responded "Linux" to a uname
command had identical output for vmstat until FC3. FC3 seems to use
similar output to BSD. I wrote a simple if-then loop to try to
determine which regex function to use, but it obivously isn't working
under fc3.

I could post the script if you'd like to look at it, but I was a little
bit afraid of looking like a total newbie. I don't get an excuse to
write code very often so it is probably quite lame.

B)


I will have a look at platform and see what I can come up with.
Delving into libraries seems a little bit much for my current level
(though lots of fun).

Thanks for the responses!

googleboy

 

[Roel Schroeven]

What this script does is use take the output of vmstat to report idle
cpu cycles (or memory stuff, etc.) over a period specified by a
parameter, all the better to be a plugin for a monitoring service.

Basically it parses the output of the command, runs through a whole
bunch of regex to discard everything not required and then reports the
info. Everything I had checked out that responded "Linux" to a uname
command had identical output for vmstat until FC3. FC3 seems to use
similar output to BSD. I wrote a simple if-then loop to try to
determine which regex function to use, but it obivously isn't working
under fc3.

In that case, it seems to be a better idea to check the version of
vmstat that's on the system. At least, I presume that such differences
in behaviour can be deduced from the vmstat version string.

 

[Mike Meyer]

In that case, it seems to be a better idea to check the version of
vmstat that's on the system. At least, I presume that such differences
in behaviour can be deduced from the vmstat version string.

Hmm. That doesn't seem to work here:

guru% vmstat --version
vmstat: illegal option -- -
usage: vmstat [-aimsz] [-c count] [-M core [-N system]] [-w wait]
[-n devs] [disks]
guru% what $(which vmstat)
/usr/bin/vmstat:
Copyright (c) 1980, 1986, 1991, 1993

The man page doesn't turn up any information on how to extract a
version for vmstat, either.

vmstat isn't a very unixish program. It's output clearly wasn't
designed to be used as input to other programs.

<mike

 

[Roel Schroeven]

In that case, it seems to be a better idea to check the version of
vmstat that's on the system. At least, I presume that such differences
in behaviour can be deduced from the vmstat version string.

Hmm. That doesn't seem to work here:

guru% vmstat --version
vmstat: illegal option -- -
usage: vmstat [-aimsz] [-c count] [-M core [-N system]] [-w wait]
[-n devs] [disks]

The version on Debian Woody uses -V:

$ vmstat -V
procps version 2.0.7

Apparently it is quite a different program than yours; the -V option is
cleary labeled in the man page, and it supports much less options:

$ vmstat --help
usage: vmstat [-V] [-n] [delay [count]]
-V prints version.
-n causes the headers not to be reprinted regularly.
delay is the delay between updates in seconds.
count is the number of updates.

 

[Mike Meyer]

In that case, it seems to be a better idea to check the version of
vmstat that's on the system. At least, I presume that such differences
in behaviour can be deduced from the vmstat version string.

Hmm. That doesn't seem to work here:
guru% vmstat --version
vmstat: illegal option -- -
usage: vmstat [-aimsz] [-c count] [-M core [-N system]] [-w wait]
[-n devs] [disks]

The version on Debian Woody uses -V:

$ vmstat -V
procps version 2.0.7

Apparently it is quite a different program than yours; the -V option
is cleary labeled in the man page, and it supports much less options:

-V doesn't work here:
guru% vmstat -V
vmstat: illegal option -- V
usage: vmstat [-aimsz] [-c count] [-M core [-N system]] [-w wait]
[-n devs] [disks]

Of course, you could use the fact that various things *don't* work
as a hint to what version of vmstat you have. I'd be interested in
what other BSD's did - especially with "what $(which vmstat)".

<mike

 

[googleboy]

I did somethign that really seems far brighter... approaching it from
a slightly different angle I just search through each line for the
right field title, and then take that field's value from teh last line
of output.

Doesn't matter what OS, doesn't matter what format now. It can cope
with it all.



Thanks for the advice! I learned a bunch.