Output of "uname -s" and "uname -o"
Tue Jun 10 13:02:00 GMT 2008
On Tue, 10 Jun 2008, Eric Blake wrote:
> 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).
Yes, I got confused. I meant uname(1). Apologies.
> > 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
Right. Extending the length of the version field and cramming the
underlying Windows info there is exactly what I was proposing. I can see
that the above sounded like I wanted a new field there -- sorry for the
> > > 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.
I was thinking of something a bit shorter, as in
uname [-s] => Cygwin
uname -o => Cygwin
uname -v => 1.5.25(0.156/4/2) NT_5.1SP3
uname -r => 2008-05-26 20:37
This should keep the output of 'uname -a' at around the current length...
> 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).
Correct. Also base-files will need to change, and the various service
config scripts (sshd, cron, etc). The latter is made easier by the common
functionality script that it seems will be used for 1.7...
|\ _,,,---,,_ firstname.lastname@example.org | email@example.com
ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"That which is hateful to you, do not do to your neighbor. That is the whole
Torah; the rest is commentary. Go and study it." -- Rabbi Hillel
More information about the Cygwin-developers