Output of "uname -s" and "uname -o"

[Eric Blake]

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