GNU bug report logs - #7991
bug in uname (?)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7991 in the body.
You can then email your comments to 7991 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Noel Kuntze <noel <at> familie-kuntze.de>
To: bug-coreutils <at> gnu.org
Subject: bug in uname (?)
Date: Sat, 5 Feb 2011 21:31:02 +0100

Hi,

It seems to me that the options for uname, more precise, -v and -r have
been interchanged.

Extract from the shell:

thermi <at> debian:~$ uname -v
#1 SMP Thu Jan 27 00:28:05 UTC 2011
thermi <at> debian:~$ uname -r
2.6.26-2-686

sincerely yours,

Noel Kuntze

____________
Virus checked by G Data AntiVirus
Version: AVA 21.4667 dated 05.02.2011
Virus news: www.antiviruslab.com

Message #8 received at 7991 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: noel <at> familie-kuntze.de
Cc: 7991 <at> debbugs.gnu.org
Subject: Re: bug#7991: bug in uname (?)
Date: Sat, 05 Feb 2011 15:13:28 -0700

[Message part 1 (text/plain, inline)]

On 02/05/2011 01:31 PM, Noel Kuntze wrote:
> Hi,
> 
> It seems to me that the options for uname, more precise, -v and -r have
> been interchanged.

Thanks for the report.  However, this is not a bug.

> 
> Extract from the shell:
> 
> thermi <at> debian:~$ uname -v
> #1 SMP Thu Jan 27 00:28:05 UTC 2011
> thermi <at> debian:~$ uname -r
> 2.6.26-2-686

Look at 'man 2 uname'.  On Linux, the uname.release version contains a
numeric string.  The uname.version field is not documented as to it's
contents, but POSIX merely requires that release and version together
identify the operating system kernel.  As confusing as it may be, this
behavior is a kernel choice, and coreutils uname(1) has no control over
it.  Coreutils is accurately reporting what the kernel told it.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 7991 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 7991 <at> debbugs.gnu.org, Noel Kuntze <noel <at> familie-kuntze.de>
Subject: Re: bug#7991: bug in uname (?)
Date: Sat, 5 Feb 2011 16:12:41 -0700

Noel Kuntze wrote:
> It seems to me that the options for uname, more precise, -v and -r have
> been interchanged.

The uname program dates back to the days of yore before we had refined
networking to the mature state that it is now.  It is really a
terrible interface.  Although we often use 'uname -a' to identify
systems it isn't out of love but simple practicality that there isn't
much better available.

If you collected the output of uname with various options on every
different system you could find you would have quite a collection of
random output!  At that point you would understand the problem.

The only portable use of uname is without arguments.  To use it
portably you can only really use it first to figure out which system
you are on and then follow that up with subsequent calls with system
specific options.  I often do this type of thing in scripts:

case $(uname) in
  HP-UX)
    case $(uname -m) in
      9000/*)
	case $(getconf CPU_VERSION) in
	  528) mach=hppa1.1 ;;
	  532) mach=hppa2.0 ;;
	  768) mach=ia64 ;;
	esac
	;;
      *) mach=$(uname -m) ;;
    esac
    sys=hpux$(uname -r | sed 's/^[AB]\.//')
    ;;
  Linux)
    sys=gnulinux
    mach=$(uname -m)
    ;;
  AIX)
    sys=aix
    mach=rs6000
    ...
    ;;
esac

That is just an example.  Such as for AIX I would need to do more but
I didn't want to keep going with the example.

Bob

Message #16 received at 7991 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: noel <at> familie-kuntze.de, 7991 <at> debbugs.gnu.org
Subject: Re: bug#7991: bug in uname (?)
Date: Mon, 07 Feb 2011 08:48:40 -0700

[Message part 1 (text/plain, inline)]

[re-adding the list]

On 02/05/2011 06:23 PM, Noel Kuntze wrote:
>> Look at 'man 2 uname'.  On Linux, the uname.release version contains a
>> numeric string.  The uname.version field is not documented as to it's
>> contents, but POSIX merely requires that release and version together
>> identify the operating system kernel.  As confusing as it may be, this
>> behavior is a kernel choice, and coreutils uname(1) has no control over
>> it.  Coreutils is accurately reporting what the kernel told it.
>>
> 
> Hi,
> 
> OK, i understood that.
> However although i run several different Linuxes i didn't use uname on
> any other than Debian.
> To "fix" this bug, one should really talk to the developers of the
> different distributions.

The different Linux distros all use the same uname(2) behavior of the
kernel.  You only need patch the kernel to swap those two fields, but
given historical compatibility, you have a very hard battle in front of
you for getting such a patch to be approved.

You're better off learning to live with the fields as currently defined
by the kernel, in spite of what you feel is an apparent naming confusion.

> This "bug" (i'll call it "bug" in the future, because "weird behaviour
> of the Kernel" is just too long) nearly got me a worse mark (we wrote a
> test about Debian Linux and the last task was to write down the kernel
> version....).

Again, it's not a bug in coreutils, but a feature of your kernel's
uname(2) implementation.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.