Oliver Bandel wrote: 
> On Thu, Jul 08, 2010 at 06:01:24PM +0100, Richard Jones wrote:
> > On Thu, Jul 08, 2010 at 10:42:40AM -0500, Romain Beauxis wrote:
> > > Le jeudi 8 juillet 2010 06:44:34, Richard Jones a écrit :
> > > > Stdlib could bind the uname(2) syscall, but it's legendary in its
> > > > complexity.  Seems more likely to cause problems than just calling
> > > > out to the external program.
> > >
> > > I fail to see the complexity.. Where is it ?
> >
> > Actually *I* misunderstood the link I posted
> > (http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NO
> > TES) thinking it meant that the string fields in the structure could
> > have variable width.  Reading it again, they don't.
> >
> > Nevertheless I still think this is not a useful addition to stdlib,
> > but for different reasons:
> >
> > (1) You'd have to emulate it on non-Unix platforms, but it's unclear
> > what you'd emulate it with.  Windows has a completely different and
> > much richer concept of OS version.  This sort of version probing
> > complexity doesn't belong in the core library, but in an external "OS
> > version" library where detection rules can be frequently updated.
> [...]
> 
> 
> $ uname -a
> 
> If it's not Unix, what will uname(2) or uname(1) give you?
> 
> What will be reported on Windows with MinGW

C:\Users\DRA>uname -a
windows32 Tenor 2.6.1 7600 i686-pc Intel unknown MinGW

(using GnuWin32 which is a MinGW build of the Unix tools)

> or Cygwin?

DRA@Tenor ~
$ uname -a
CYGWIN_NT-6.1-WOW64 Tenor 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

But of course in both instances that requires uname.exe to be installed which it won't be on most normal end-user systems.


David