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