On 20/07/15 22:16, Assaf Gordon wrote: > 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
BTW for a more direct/portable method, one might consider: test "$(getconf LONG_BIT)" = '64' Also that would work better in a 32 chroot on 64 bit kernel. > > For some 'uname -m' values of common OSes (not just Linux-based), see here: > http://pretest.nongnu.org/versions/ Very useful info thanks! I see this was also discussed at: http://bugs.gnu.org/13001 http://bugs.gnu.org/15757 Some quick testing here gives: System uname -i uname -m uname -p ---------------------------------------------------------------- OS X - coreutils Macmini7,1 x86_64 i386 OS X - native illegal option x86_64 i386 Solaris 10 SUNW,SPARC... sun4v sparc Fedora 22 x86_64 x86_64 x86_64 GNU/Linux unknown x86_64 unknown I find it incorrect that the Linux distros just copied -m to -i and -p. BTW for a script using -m and -p (but not -i) values see: http://git.sv.gnu.org/gitweb/?p=gnulib.git;f=build-aux/config.guess;hb=HEAD I wonder should be just be more explicit about discouraging use of the -i and -p options, and leave it at that. That's done in the attached. thanks, Pádraig.
From ef5473d3c1828d1be2ea7d5f3bd3c211818c81c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= <p...@draigbrady.com> Date: Tue, 21 Jul 2015 10:17:43 +0100 Subject: [PATCH] doc: discourage use of uname -i and -p options * src/uname.c (usage): State that the non POSIX -i and -p options are non portable. * doc/coreutils.texi (uname invocation): Mention the discrepancies even across GNU/Linux distros, and that the results should be used as informational only, rather than impacting any logic decisions. --- doc/coreutils.texi | 8 ++++---- src/uname.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/coreutils.texi b/doc/coreutils.texi index 5808413..6a07dcb 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -15605,8 +15605,8 @@ and the hardware platform name if they are unknown. @cindex platform, hardware Print the hardware platform name (sometimes called the hardware implementation). -Print @samp{unknown} if the kernel does not make this information -easily available, as is the case with Linux kernels. +Print @samp{unknown} if this information is not available. +Note this is non portable (even across GNU/Linux distributions). @item -m @itemx --machine @@ -15634,8 +15634,8 @@ Print the network node hostname. @cindex host processor type Print the processor type (sometimes called the instruction set architecture or ISA). -Print @samp{unknown} if the kernel does not make this information -easily available, as is the case with Linux kernels. +Print @samp{unknown} if this information is not available. +Note this is non portable (even across GNU/Linux distributions). @item -o @itemx --operating-system diff --git a/src/uname.c b/src/uname.c index 39bd28c..a9aec56 100644 --- a/src/uname.c +++ b/src/uname.c @@ -133,8 +133,8 @@ Print certain system information. With no OPTION, same as -s.\n\ fputs (_("\ -v, --kernel-version print the kernel version\n\ -m, --machine print the machine hardware name\n\ - -p, --processor print the processor type or \"unknown\"\n\ - -i, --hardware-platform print the hardware platform or \"unknown\"\n\ + -p, --processor print the processor type. Non portable\n\ + -i, --hardware-platform print the hardware platform. Non portable\n\ -o, --operating-system print the operating system\n\ "), stdout); } -- 2.4.1