GNU bug report logs - #14388
Bug in uname command - reg...

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 14388 in the body.
You can then email your comments to 14388 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: vevek venkatesan <vevekvece <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Bug in uname command - reg...
Date: Sat, 11 May 2013 12:53:10 +0530

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

Hi Team,
              In uname command In feel that there is a bug with -r and -v
options which I describe as follows,

uname -r -> it should show the release of kernel
uname -v -> it should show the version of kernel as per your manual page,
but it is showing vice-versa of each.

Thanks & Regards,
- Vevek V

[Message part 2 (text/html, inline)]

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

From: Bob Proulx <bob <at> proulx.com>
To: vevek venkatesan <vevekvece <at> gmail.com>
Cc: 14388 <at> debbugs.gnu.org
Subject: Re: bug#14388: Bug in uname command - reg...
Date: Sat, 11 May 2013 17:46:24 -0600

tag 14388 + moreinfo notabug
thanks

vevek venkatesan wrote:
>               In uname command In feel that there is a bug with -r and -v
> options which I describe as follows,
> 
> uname -r -> it should show the release of kernel
> uname -v -> it should show the version of kernel as per your manual page,
> but it is showing vice-versa of each.

Thank you for the report.  However the uname(1) command simply calls
the uname(2) system call.  It then reports what the kernel has stored
there.  It is a very old command having been around a very long time.
I don't think there is a bug there.

But you did not report the information that you are seeing.  If you
would be so kind as to report what you are seeing then perhaps we
would be able to know what is happening for you.  Since you didn't
tell us what you are seeing there isn't any way for us to know one way
or the other.  When reporting bugs it is necessary to show us what it
is doing for you.

In any case, here is a sample from my system.  This is the correct
output for my system.  Note that on other systems the values stored by
the kernel can be quite a bit different.  Especially on HP-UX and on
IBM AIX the output may be quite different!

  $ uname -r
  3.2.0-4-amd64

  $ uname -v
  #1 SMP Debian 3.2.35-2

Really the only portable way to use uname(1) is to call it first to
see which system name it returns and then after knowing the system
type then call it again with whatever options make sense on that
system.

Bob

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

From: Linda Walsh <coreutil <at> tlinx.org>
To: Bob Proulx <bob <at> proulx.com>
Cc: 14388 <at> debbugs.gnu.org, vevek venkatesan <vevekvece <at> gmail.com>
Subject: Re: bug#14388: Bug in uname command - reg...
Date: Sat, 11 May 2013 21:58:14 -0700

Bob Proulx wrote:

> 
>   $ uname -r
>   3.2.0-4-amd64
> 
>   $ uname -v
>   #1 SMP Debian 3.2.35-2
---
I get something similiar the above, but that isn't the way
the kernel terminology -- despite the fact that use "uname-r" to search for the
kernel-version of modules
to use.

but 3=VERSION
2=PATCHLEVEL
0=SUBLEVEL
-4- = EXTRAVERSION
-amd64=LOCALVERSION

From that -- it looks quite a bit like it describing version information.
On mine, I have
uname -r=3.9.0-Isht-Van

With Isht-Van being my localversion name
The uname-v has:
#6 SMP PREEMPT Wed May 8 17:28:40 PDT 2013
Compile#, options date.... not sure why debians is different --- 3.2.35-2?

That's odd looking.

It looks like they are a bit backwards -- but I think I would agree with
Bob's assessment that it can't be something that is fixed since there
are tons of programs (including programs IN THE KERNEL (to load modules))
that use the 'release' to get the linux-version info...

*doh!*


> 
> Really the only portable way to use uname(1) is to call it first to
> see which system name it returns and then after knowing the system
> type then call it again with whatever options make sense on that
> system.
---
	Which is a bit like saying you need an interpreter that's
system specific to pick out what is relevant.  That's special! ;->

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

From: Bob Proulx <bob <at> proulx.com>
To: 14388 <at> debbugs.gnu.org
Cc: vevek venkatesan <vevekvece <at> gmail.com>
Subject: Re: bug#14388: Bug in uname command - reg...
Date: Sun, 12 May 2013 18:54:27 -0600

Linda Walsh wrote:
> Bob Proulx wrote:
> >   $ uname -r
> >   3.2.0-4-amd64
> >   $ uname -v
> >   #1 SMP Debian 3.2.35-2
>
> From that -- it looks quite a bit like it describing version information.
> On mine, I have
> uname -r=3.9.0-Isht-Van
> 
> With Isht-Van being my localversion name
> The uname-v has:
> #6 SMP PREEMPT Wed May 8 17:28:40 PDT 2013
> Compile#, options date.... not sure why debians is different --- 3.2.35-2?
> 
> That's odd looking.

IBM AIX 3.5 returns information like this:

  $ uname -a
  AIX localhost 3 5 00CD7EAF4C00

  $ uname -r
  3

  $ uname -v
  5

HP-UX 11.31 will say something like this:

  $ uname -a
  HP-UX localhost B.11.31 U ia64 3682977672 unlimited-user license

  $ uname -r
  B.11.31

  $ uname -v
  U

Solaris 5.9:

  $ uname -a
  SunOS localhost 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-15000

  $ uname -r
  5.9

  $ uname -v
  Generic_112233-12

I don't have access to a variety of machines these days so the above
is cutting and pasting from reports sent in that I found on the web.
I may have something slightly wrong in the above.  But it should still
be illustrative that every system interprets what to do with the
fields differently.

> It looks like they are a bit backwards -- but I think I would agree with
> Bob's assessment that it can't be something that is fixed since there
> are tons of programs (including programs IN THE KERNEL (to load modules))
> that use the 'release' to get the linux-version info...
> 
> *doh!*

Yes.  D'oh!  Which is why it isn't as useful as people think it might be.

> > Really the only portable way to use uname(1) is to call it first to
> > see which system name it returns and then after knowing the system
> > type then call it again with whatever options make sense on that
> > system.
>
> 	Which is a bit like saying you need an interpreter that's
> system specific to pick out what is relevant.  That's special! ;->

Yes.  That is exactly what I am saying! :-)

Here is some live code from a script designed to run in a an
environment with all of the above.  This isn't general purpose and was
written to work exactly for the cases I needed it to work.  For
example for AIX I would have needed to have it combine -r and -v
together to get to 3.5 but for me knowing "aix" was good enough so I
stopped there.  I am just posting this to give an exapmle of the type
of system specific tests that are needed.  I am sure that if this
script were live working today that it would have variations for
current systems.

Bob

os=unknown
mach=unknown
uname=$(uname)
if [ $? -ne 0 ] || [ -z "$uname" ]; then
  echo "Error: Could not run 'uname'" 1>&2
  exit 1
fi
case $uname in
AIX)
  os=aix
  mach=rs6000
  ;;
HP-UX)
  case $(uname -m) in
  9000/*)
    case $(uname -r) in
      ?.10.*) mach=hppa1.1 ;;
      *)      mach=hppa2.0 ;;
    esac
    ;;
  *) mach=$(uname -m) ;;
  esac
  case $(uname -r) in
    ?.10.*)  os=hpux10 ;;
    *) os=hpux$(uname -r | sed 's/^[AB]\.//') ;;
  esac
  ;;
Linux)
  os=gnulinux
  mach=$(uname -m)
  ;;
esac

Previous Next

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