From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 20 15:43:11 2015 Received: (at submit) by debbugs.gnu.org; 20 Jul 2015 19:43:11 +0000 Received: from localhost ([127.0.0.1]:54834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHGxx-00077D-WC for submit@debbugs.gnu.org; Mon, 20 Jul 2015 15:43:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38141) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHGia-00066U-6E for submit@debbugs.gnu.org; Mon, 20 Jul 2015 15:27:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHGiT-000856-UR for submit@debbugs.gnu.org; Mon, 20 Jul 2015 15:27:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:50488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHGiT-000850-RE for submit@debbugs.gnu.org; Mon, 20 Jul 2015 15:27:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHGiS-00014s-GR for bug-coreutils@gnu.org; Mon, 20 Jul 2015 15:27:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHGiO-000847-64 for bug-coreutils@gnu.org; Mon, 20 Jul 2015 15:27:08 -0400 Received: from relay1.webreus.nl ([46.235.43.249]:36206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHGiN-00083X-Sb for bug-coreutils@gnu.org; Mon, 20 Jul 2015 15:27:04 -0400 Received: from srv253033.webreus.nl (srv045033.webreus.nl [46.235.45.33]) by relay1.webreus.nl (Postfix) with ESMTP id C9B15485C104 for ; Mon, 20 Jul 2015 21:27:00 +0200 (CEST) Received: (qmail 5976 invoked from network); 20 Jul 2015 21:27:00 +0200 Received: from 82-136-210-153.ip.telfort.nl (HELO ren) (82.136.210.153) by srv045033.webreus.nl with (DHE-RSA-AES128-SHA encrypted) SMTP; 20 Jul 2015 21:27:00 +0200 Date: Mon, 20 Jul 2015 21:26:59 +0200 From: Norbert de Jonge To: bug-coreutils@gnu.org, djm@djmnet.org Subject: uname man page Message-ID: <20150720212659.44bedb08@ren> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 20 Jul 2015 15:43:08 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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. I think a good way to explain the problem is by giving an example. My example mentions proprietary software, but the problem occurs in many other settings. The game engine Unity can deploy to GNU/Linux. A game developer creates a 64-bit executable and a customer requests 32-bit support in a post on the game's Steam Community Hub. Someone mentions to the indie developer that a shell script that uses uname could do the trick. The developer looks at the uname man page, reads "print the hardware platform" for -i and decides to try this out on Ubuntu. It returns "x86_64" for the developer's 64-bit machine. After a bit of reading about bash the result is something like: if [ `uname -i` = x86_64 ] then ./game_64 else ./game_32 fi 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. But, if I'm not mistaken, the only POSIX option of those three is -m: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html For -m, The Open Group's publication says "Write the name of the hardware TYPE" (emphasis mine). The GNU coreutils man page for uname says -m will "print the machine hardware NAME", while -i says "print the hardware PLATFORM". The latter /seems/ to be the most relevant option even though it's not. 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". The man page could also use a POSIX section. In fact, it would be better if the section that describes the options, near those three similar ones, would say which of those is the POSIX variant and maybe even that "If you want to determine whether a system is 32-bit or 64-bit, use this option." Really. I really think we can't help out people enough. Even "processor type" (-p) returns x86_64 on many/most distros, and may (thus) also trick developers and users into thinking that's the thing they're looking for. Best regards, Norbert de Jonge From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 20 17:16:40 2015 Received: (at 21098) by debbugs.gnu.org; 20 Jul 2015 21:16:40 +0000 Received: from localhost ([127.0.0.1]:54854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHIQS-0003cy-A7 for submit@debbugs.gnu.org; Mon, 20 Jul 2015 17:16:40 -0400 Received: from mail-qk0-f174.google.com ([209.85.220.174]:34508) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHIQQ-0003ch-Io for 21098@debbugs.gnu.org; Mon, 20 Jul 2015 17:16:39 -0400 Received: by qkfc129 with SMTP id c129so78080546qkf.1 for <21098@debbugs.gnu.org>; Mon, 20 Jul 2015 14:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+nYu7Q98UurKvlUI6K/1XAprKlMOC+f9y3HrJqDiQFY=; b=rjisWcxeeW46EzyUQ4OSQiYmYIZWzs0LFGux3LsRI998TJTIuogY3fEMHSNEqKHEX0 xs99ltJDJ06flzum4a6hpTOCQFZ4BdjNEf6JmXyP1Rbkf0XQD7LV7R/AuiG0vkOeVjto l2JYyU7vVc3BufwowbG9Fk2+6c//5p1bmd3xdpazLI2zkq+GQGzaND/AxdkA+a4LMDxj st6506JY5ivi/Ujkh7FVJeK7gLi43O+YJJDy5t1H18NW7ed72OXP2y8EXHBF/k/JTfAM Tx49/FhyItgl7QZD2xvMg15uXOc4K6EJaO9l80msMZvXiFAlf3qmexkk7R9GvTas9xj1 hG/g== X-Received: by 10.55.19.40 with SMTP id d40mr12920988qkh.15.1437426993190; Mon, 20 Jul 2015 14:16:33 -0700 (PDT) Received: from disco.erlich.nygenome.org ([162.212.111.2]) by smtp.googlemail.com with ESMTPSA id 10sm11621859qgl.9.2015.07.20.14.16.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2015 14:16:32 -0700 (PDT) Message-ID: <55AD6538.1060607@gmail.com> Date: Mon, 20 Jul 2015 17:16:40 -0400 From: Assaf Gordon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Norbert de Jonge , 21098@debbugs.gnu.org, djm@djmnet.org Subject: Re: bug#21098: uname man page References: <20150720212659.44bedb08@ren> In-Reply-To: <20150720212659.44bedb08@ren> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21098 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 21 01:26:34 2015 Received: (at 21098) by debbugs.gnu.org; 21 Jul 2015 05:26:34 +0000 Received: from localhost ([127.0.0.1]:54946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHQ4X-0006pz-KM for submit@debbugs.gnu.org; Tue, 21 Jul 2015 01:26:33 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:52798) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHQ4V-0006pm-4w for 21098@debbugs.gnu.org; Tue, 21 Jul 2015 01:26:31 -0400 Received: from [192.168.101.10] ([217.86.93.54]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0MQZS8-1ZMt9f20lQ-00Tk4O; Tue, 21 Jul 2015 07:26:23 +0200 Message-ID: <55ADD7FE.7090002@bernhard-voelker.de> Date: Tue, 21 Jul 2015 07:26:22 +0200 From: Bernhard Voelker User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Norbert de Jonge , 21098@debbugs.gnu.org, djm@djmnet.org Subject: Re: bug#21098: uname man page References: <20150720212659.44bedb08@ren> In-Reply-To: <20150720212659.44bedb08@ren> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TN7j3nOR0ixiVSwM0egu97Xbfnohg6CP+P8d3Zcryu1XspCZkLR r4JCGRB8wZB9HCuNJp9aWqOjJHP9+rpGoiGjV4KTgOPy8Tp9fIz8WpN7vIqYMhgmU5+1rQ3 003zCU/k+CmsOYjHLYJKMdQ0/zyZZn6FAOnrRiUMZopCf3mMnZFYSztmaEto5BviYLgyWk7 0sZbmODVz0IjLxGt9bsfA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Vzdy8m36wsw=:Oger4Mjx0w+83dKss6CUrC +F1+XRQvH+7DbXY56Vep4Pb9pamezB4wY+/E+xjz35k/7UEBhq25lP3eIMHpcquWmDn3iY4bY SI+jtGQEk5QrH73WUtA2NdlHpyixhDehm0WFjjhbOJQswdz7ItG1D/8brYMk7fcCm6E255tDv /kfr/G/LfGSAJe9ojmtB31rF46i2d37q/wgImzLpq43Gf1b5ga6zy3X6G1E7/ImzKTTqiGwRk vKyUhryDrQWufOsDJTT6KNglFU3EOPYNrG5pu8lvGOP5ghx9B/t3YjmW6P0nqEGzb5LBYkjGY vqRhpxWObNLYhrH640aRxcJH7NylnkHUp/j+T6BNeCO/shv8rXJvEdZhVWSODaNFCtQdeoEim 9l9mnZA/xu/TtG9OG1SXFINAP4GKrEppPHUY4Zzfp+TGrghE1nbwx/EGxIHVOhrE2MP1dfVxC l+WJTV7Gskj3psT7XtHBSBZ+Hb0iP0rQXv1+aIFz/1IpWLgCjk6wDPsgJ0RLjmv17/tZS+6BN LHF5wi2Xe9tkUtqnfP97zGFC0k7/1EVlbbDCicaK9QEtn1c/UWkq/8dL0vk/byCsbyAg94QpG Gy0DnadgazhcoljPq60D5d/gr+fmFc54/OZLAlCDiDPSE5mz+3FtB6CmnqfLJrR8HY0wD5gBb aWNJVyUCZrrBMYeeeIbNyDI3/+SPKnhJk0tcBXEmcs97jVg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21098 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 07/20/2015 09: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. Thanks for the report. Additionally to Assaf's answer, I want to mention that the man page of GNU coreutils utilities is (almost) identically to the --help output which we want to keep terse. Actually the former is generated from the latter. At the end of the man page, there is the reference to the real documentation: The full documentation for uname is maintained as a Texinfo manual. If the info and uname programs are properly installed at your site, the command info '(coreutils) uname invocation' should give you access to the complete manual. Now let's look at -m, -p, and -i there: `-i' `--hardware-platform' Print the hardware platform name (sometimes called the hardware implementation). Print `unknown' if the kernel does not make this information easily available, as is the case with Linux kernels. `-m' `--machine' Print the machine hardware name (sometimes called the hardware class or hardware type). `-p' `--processor' Print the processor type (sometimes called the instruction set architecture or ISA). Print `unknown' if the kernel does not make this information easily available, as is the case with Linux kernels. Is this sufficient for you? Otherwise feel free to suggest a better wording - preferably as a git patch or a regular diff, but we could also wrap it into a proper patch for you. Thanks & have a nice day, Berny From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 21 05:52:14 2015 Received: (at 21098) by debbugs.gnu.org; 21 Jul 2015 09:52:14 +0000 Received: from localhost ([127.0.0.1]:54986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHUDd-0004zt-13 for submit@debbugs.gnu.org; Tue, 21 Jul 2015 05:52:13 -0400 Received: from mail1.vodafone.ie ([213.233.128.43]:52657) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHUDa-0004zf-8K for 21098@debbugs.gnu.org; Tue, 21 Jul 2015 05:52:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwHAN4VrlVtTITg/2dsb2JhbABcgkFSVGMGglSwaYo+DIJBgzsBAgKBNUwBAQEBAQGBC4QjAQEBAwEBAoEGCw0EAQIBAgEJFg8JAwIBAgEWIQYIBgEMBgIBAQWIHQwBAwW5HpBoAQEBAQEBBAEBAQEBAQEbi0yELUgMDIQrBYcOhSqFI4J4gjaBV2iEXoQaRoNWgwSJDYceJoN9PTEBAQGBAYFHAQEB Received: from unknown (HELO localhost.localdomain) ([109.76.132.224]) by mail1.vodafone.ie with ESMTP; 21 Jul 2015 10:52:02 +0100 Message-ID: <55AE163F.8010704@draigBrady.com> Date: Tue, 21 Jul 2015 10:51:59 +0100 From: =?windows-1252?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Assaf Gordon , Norbert de Jonge , 21098@debbugs.gnu.org, djm@djmnet.org Subject: Re: bug#21098: uname man page References: <20150720212659.44bedb08@ren> <55AD6538.1060607@gmail.com> In-Reply-To: <55AD6538.1060607@gmail.com> Content-Type: multipart/mixed; boundary="------------040501080202000108070803" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 21098 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is a multi-part message in MIME format. --------------040501080202000108070803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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. --------------040501080202000108070803 Content-Type: text/x-patch; name="coreutils-uname-ip.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="coreutils-uname-ip.patch" =46rom ef5473d3c1828d1be2ea7d5f3bd3c211818c81c6 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?P=3DC3=3DA1draig=3D20Brady?=3D 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 unknow= n. @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). =20 @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). =20 @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, sa= me 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); } --=20 2.4.1 --------------040501080202000108070803-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 21 09:35:04 2015 Received: (at 21098) by debbugs.gnu.org; 21 Jul 2015 13:35:04 +0000 Received: from localhost ([127.0.0.1]:55099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHXhF-0003F0-Ky for submit@debbugs.gnu.org; Tue, 21 Jul 2015 09:35:02 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51903) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHXhC-0003EK-HG for 21098@debbugs.gnu.org; Tue, 21 Jul 2015 09:34:59 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9FF301609A5; Tue, 21 Jul 2015 06:34:52 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id RQ_7-IMxZ6b3; Tue, 21 Jul 2015 06:34:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CCD6F160CB6; Tue, 21 Jul 2015 06:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wOddKXDwI8F3; Tue, 21 Jul 2015 06:34:51 -0700 (PDT) Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id A88B61609A5; Tue, 21 Jul 2015 06:34:51 -0700 (PDT) Message-ID: <55AE4A77.7010004@cs.ucla.edu> Date: Tue, 21 Jul 2015 06:34:47 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= , Assaf Gordon , Norbert de Jonge , 21098@debbugs.gnu.org, djm@djmnet.org Subject: Re: bug#21098: uname man page References: <20150720212659.44bedb08@ren> <55AD6538.1060607@gmail.com> <55AE163F.8010704@draigBrady.com> In-Reply-To: <55AE163F.8010704@draigBrady.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 21098 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.2 (-) Thanks, that patch looks good, except for some nits. POSIX spells the phrase "non-portable" and we might as well be consistent. The --help lines would look better as: -p, --processor print the processor type (non-portable)\n\ -i, --hardware-platform print the hardware platform (non-portable)\n\ as the period would look funny after a non-capitalized sentence. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 21 20:55:16 2015 Received: (at 21098) by debbugs.gnu.org; 22 Jul 2015 00:55:16 +0000 Received: from localhost ([127.0.0.1]:55823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHiJY-00028Q-1y for submit@debbugs.gnu.org; Tue, 21 Jul 2015 20:55:16 -0400 Received: from mail1.vodafone.ie ([213.233.128.43]:65340) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHiJV-000283-Md; Tue, 21 Jul 2015 20:55:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAKbprlVtTITg/2dsb2JhbABcDguCKlKCfIEWvmSCXgKBQUwBAQEBAQGBC4QkAQEEIw8BVgsNCwICBRYLAgIJAwIBAgFFBgEMCAEBiC4BtXqFbpBKASuBIooqhQ2CaIFDBZRTlQ2QKyaDPj89gnwBAQE Received: from unknown (HELO localhost.localdomain) ([109.76.132.224]) by mail1.vodafone.ie with ESMTP; 22 Jul 2015 01:54:58 +0100 Message-ID: <55AEE9E2.5070604@draigBrady.com> Date: Wed, 22 Jul 2015 01:54:58 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Paul Eggert , Assaf Gordon , Norbert de Jonge , 21098@debbugs.gnu.org, djm@djmnet.org Subject: Re: bug#21098: uname man page References: <20150720212659.44bedb08@ren> <55AD6538.1060607@gmail.com> <55AE163F.8010704@draigBrady.com> <55AE4A77.7010004@cs.ucla.edu> In-Reply-To: <55AE4A77.7010004@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 21098 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) unarchive 13001 unarchive 15757 forcemerge 13001 15757 21098 close 13001 stop On 21/07/15 14:34, Paul Eggert wrote: > Thanks, that patch looks good, except for some nits. POSIX spells the phrase > "non-portable" and we might as well be consistent. The --help lines would look > better as: > > -p, --processor print the processor type (non-portable)\n\ > -i, --hardware-platform print the hardware platform (non-portable)\n\ > > as the period would look funny after a non-capitalized sentence. Done and pushed. I've closed the bugs now since we've discouraged use of these options. Since they're platform specific, any logic changes should be in uname(1) and/or the kernel. thanks, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 22 05:34:06 2015 Received: (at 21098) by debbugs.gnu.org; 22 Jul 2015 09:34:06 +0000 Received: from localhost ([127.0.0.1]:56084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHqPd-0007G9-K4 for submit@debbugs.gnu.org; Wed, 22 Jul 2015 05:34:05 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:38691) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHqPb-0007Fe-3Z for 21098@debbugs.gnu.org; Wed, 22 Jul 2015 05:34:03 -0400 Received: by wibxm9 with SMTP id xm9so92913597wib.1 for <21098@debbugs.gnu.org>; Wed, 22 Jul 2015 02:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=KS1nc6onvnmSQkeUd+9mDhJIle4K92VOrdHuzhQKkTk=; b=d7M99s3RE2s6K+vMeZNYMsZ54W75T38iJ/OvrL/WvIybwDtBxjqaFKkwM99xWUOYoz LMC+VRGCeR5DvZdHMyjnXdPmIzW9H9BqvCVaUWWwGf60Md/w3fDTrffCc3Qv5tuch/F5 S3pQws4DC5KQ0UodUKMk4+yg47ZGimtZNM0/9OBLKy2LbqqugpRgvXOpS3D5MBTK/E0H IB7qJScQbCbwM1eZiu2Tl2o6WjqcujSLDo91Zo3zQvnLRzLXdBwQZOWS63GLcD9Wxrif 5UV8AVUUrSEcdqQP9kMWmYWQLQEpyNPUGgTU4Pe8OxbWTXdhEUhNiWBFpKqHmY7k96vt BIyg== X-Received: by 10.194.179.136 with SMTP id dg8mr3030189wjc.49.1437557637348; Wed, 22 Jul 2015 02:33:57 -0700 (PDT) Received: from chaz.gmail.com ([90.200.231.204]) by smtp.gmail.com with ESMTPSA id r8sm15794681wiz.5.2015.07.22.02.33.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jul 2015 02:33:56 -0700 (PDT) Date: Wed, 22 Jul 2015 10:33:55 +0100 From: Stephane Chazelas To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#21098: uname man page Message-ID: <20150722093355.GA10910@chaz.gmail.com> References: <20150720212659.44bedb08@ren> <55AD6538.1060607@gmail.com> <55AE163F.8010704@draigBrady.com> <55AE4A77.7010004@cs.ucla.edu> <55AEE9E2.5070604@draigBrady.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55AEE9E2.5070604@draigBrady.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 21098 Cc: Norbert de Jonge , Assaf Gordon , Paul Eggert , 21098@debbugs.gnu.org, djm@djmnet.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 2015-07-22 01:54:58 +0100, Pádraig Brady: [...] > On 21/07/15 14:34, Paul Eggert wrote: > > Thanks, that patch looks good, except for some nits. POSIX spells the phrase > > "non-portable" and we might as well be consistent. The --help lines would look > > better as: > > > > -p, --processor print the processor type (non-portable)\n\ > > -i, --hardware-platform print the hardware platform (non-portable)\n\ > > > > as the period would look funny after a non-capitalized sentence. > > Done and pushed. > I've closed the bugs now since we've discouraged use of these options. > Since they're platform specific, any logic changes should be > in uname(1) and/or the kernel. [...] Note that for Solaris, it's -m that's discouraged http://docs.oracle.com/cd/E23824_01/html/821-1461/uname-1.html -p is useful as it gives (is meant to give) the instruction-set. Although not POSIX, it's fairly portable. Among the modern (and less modern) Unix players, I could only find HP/UX not supporting it. -- Stephane From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 22 06:27:34 2015 Received: (at 21098) by debbugs.gnu.org; 22 Jul 2015 10:27:34 +0000 Received: from localhost ([127.0.0.1]:56097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHrFO-00005O-5s for submit@debbugs.gnu.org; Wed, 22 Jul 2015 06:27:34 -0400 Received: from mail1.vodafone.ie ([213.233.128.43]:16328) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZHrFL-00005A-8z for 21098@debbugs.gnu.org; Wed, 22 Jul 2015 06:27:31 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEGAMlvr1VtTITg/2dsb2JhbABbgkNSHzVpvXuGAQKBR0wBAQEBAQGBC4QkAQEEMgFGEAsNCwklDwJGBg0BBwEBiC4BCLtvkEsBAQEHAgEfi0yFBgeEKwWUV4R1iUaGWpAuJoN9PTEBgkoBAQE Received: from unknown (HELO localhost.localdomain) ([109.76.132.224]) by mail1.vodafone.ie with ESMTP; 22 Jul 2015 11:27:09 +0100 Message-ID: <55AF6FFC.10405@draigBrady.com> Date: Wed, 22 Jul 2015 11:27:08 +0100 From: =?windows-1252?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephane Chazelas Subject: Re: bug#21098: uname man page References: <20150720212659.44bedb08@ren> <55AD6538.1060607@gmail.com> <55AE163F.8010704@draigBrady.com> <55AE4A77.7010004@cs.ucla.edu> <55AEE9E2.5070604@draigBrady.com> <20150722093355.GA10910@chaz.gmail.com> In-Reply-To: <20150722093355.GA10910@chaz.gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 21098 Cc: Norbert de Jonge , Assaf Gordon , Paul Eggert , 21098@debbugs.gnu.org, djm@djmnet.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 22/07/15 10:33, Stephane Chazelas wrote: > 2015-07-22 01:54:58 +0100, Pádraig Brady: > [...] >> On 21/07/15 14:34, Paul Eggert wrote: >>> Thanks, that patch looks good, except for some nits. POSIX spells the phrase >>> "non-portable" and we might as well be consistent. The --help lines would look >>> better as: >>> >>> -p, --processor print the processor type (non-portable)\n\ >>> -i, --hardware-platform print the hardware platform (non-portable)\n\ >>> >>> as the period would look funny after a non-capitalized sentence. >> >> Done and pushed. >> I've closed the bugs now since we've discouraged use of these options. >> Since they're platform specific, any logic changes should be >> in uname(1) and/or the kernel. > [...] > > Note that for Solaris, it's -m that's discouraged > http://docs.oracle.com/cd/E23824_01/html/821-1461/uname-1.html > > -p is useful as it gives (is meant to give) the instruction-set. > > Although not POSIX, it's fairly portable. Among the modern (and > less modern) Unix players, I could only find HP/UX not > supporting it. Thanks for the extra info. Just to be clear, for portability I was referring to the POSIX options, but mainly to the value itself. I.E. it's meant as a warning to have users consider use of these values. Also it's better to align with the standards and most popular platforms. thanks, Pádraig. From unknown Thu Jun 19 14:26:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 19 Aug 2015 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator