GNU bug report logs - #21098
uname man page

Previous Next

Package: coreutils;

Reported by: Norbert de Jonge <mail <at> norbertdejonge.nl>

Date: Mon, 20 Jul 2015 19:44:02 UTC

Severity: normal

Merged with 13001, 15757

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Norbert de Jonge <mail <at> norbertdejonge.nl>, 21098 <at> debbugs.gnu.org, 
 djm <at> djmnet.org
Subject: Re: bug#21098: uname man page
Date: Mon, 20 Jul 2015 17:16:40 -0400
tag 21098 notabug
stop

Hello,

On 07/20/2015 03:26 PM, Norbert de Jonge wrote:
> Maybe someone has time and energy to make some minor improvements to
> uname's man page. The problem lies in the vagueness and similarity of
> the options -m, -p and -i, combined with the program's unpredictable
> output.

The man-page could be re-worded, but,
the values that are reported by uname are very system specific.

The Coreutil FAQ contains an entry for uname:
 http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#uname-is-system-specific

And some past discussions contain more information:
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14388
  http://lists.gnu.org/archive/html/bug-coreutils/2003-10/msg00098.html
  http://lists.gnu.org/archive/html/bug-coreutils/2004-11/msg00032.html

> To make people's lives easier, the description for -m should be
> changed. I also think it would be useful to add to the description, in
> parentheses, "e.g. x86_64, i686".
[...]
> "If you want to determine whether a system is 32-bit or 64-bit, use this option."

mentioning "x86_64/i686" in the documentation is Linux-kernel specific, and coreutils is not limited to Linux-kernel, and would be incorrect/misleading on other systems (e.g. on BSD systems the returned value is "amd64").

In practice,
The values of 'uname' are not standardized over all OSes/hardwares.
The recommended way is to first detect the system/kernel type (e.g. just 'uname'),
and then decode the hardware type, using the values that are common to that kernel.
An example to such code is given here:
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14388#14

> Now, that works on Ubuntu, but not on, for example, Arch. Ubuntu, Mint
> and probably also Debian, return the same thing for -m, -p and -i.

I'm not familiar with Arch;
some GNU/Linux distros return the values reported by the Linux Kernel, and GNU coreutils does not change that value.
Other distros patch GNU coreutils (or the kernel?) to return other values.
See related discussion here:
   http://lists.gnu.org/archive/html/bug-coreutils/2012-11/msg00173.html
   http://lists.gnu.org/archive/html/bug-coreutils/2012-11/msg00177.html

I believe that if the kernel is detected as "Linux", then the developer can assume that "uname -m" would suffice (based on known Linux kernel values) [other participants - please correct me if that's wrong]:

e.g:
    test "$(uname)" = Linux \
       && test "$(uname -m)" = x86_64 \
       && echo 64bit-linux || echo other

For some 'uname -m' values of common OSes (not just Linux-based), see here:
   http://pretest.nongnu.org/versions/

HTH,
 - assaf





This bug report was last modified 9 years and 306 days ago.

Previous Next


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