[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21098: uname man page
From: |
Assaf Gordon |
Subject: |
bug#21098: uname man page |
Date: |
Mon, 20 Jul 2015 17:16:40 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
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
bug#21098: uname man page, Bernhard Voelker, 2015/07/21