[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21098: uname man page
From: |
Pádraig Brady |
Subject: |
bug#21098: uname man page |
Date: |
Tue, 21 Jul 2015 10:51:59 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
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.
coreutils-uname-ip.patch
Description: Text Data
bug#21098: uname man page, Bernhard Voelker, 2015/07/21