This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Output of "uname -s" and "uname -o"
According to Igor Peshansky on 6/9/2008 11:10 PM:
Right. The main problem is not with changing the size of the fields
(though that is helpful), but with changing the actual content of those
fields (which will break things that rely on uname(2)).
Don't you mean uname(1)? I still think there are more clients of
coreutil's uname(1) than there are C programs that call uname(2).
Does autoconf usually care whether it runs on Vista or XP or NT?
No; config.guess currently bases off of the glob CYGWIN*, and
canonicalizes to "cygwin", losing all the Windows platform data.
Right. I figured as much. We'd want to move the underlying Windows
information into some field in utsname*.
We are free to add fields to utsname. But it buys very little except for
cygwin-specific applications that know to use such fields. The easiest
way to propagate additional information is to reuse the existing fields.
Do all of the fields need to be made larger, or just sysname?
Actually, it's version and release that are filled close to capacity.
I recommended that it would be exactly "Cygwin", and that any extra
version information be released in the version field.
Again, does congif.guess care that it's running on Vista/XP/2k/NT?
No - in fact, if someone cares about cygwin on XP vs. cygwin on Vista
(perhaps because they know that XP IPv6 isn't fully baked), they are
finding that out on their own, rather than via config.guess.
And in my experience, fewer programs rely on uname -r and uname -v; and
the distinction between release and version is rather fuzzy. So what if
we made things look like this (going from my current 1.5.25 output,
although in reality the change is better for 1.7.0):
uname [-s] => Cygwin
uname -o => Cygwin
uname -r => 1.5.25(0.156/4/2) 2008-05-26 20:37
uname -v => Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 3
Or maybe abbreviate uname -v, especially since this larger struct makes
'uname -a' much larger.
We'd also need to submit a patch to config.guess to recognize "Cygwin" in
addition to "CYGWIN*" as its glob, and until various packages pick up on
that patch, a lot of applications won't configure correctly on cygwin (or
maybe we patch cygport to make it easy use the latest-and-greatest
config.guess rather than the outdated one shipped with a package).
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net