Debian Bug report logs - #193170
uname: -i and -p options give unhelpful answers

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ben Harris <bjh21@cam.ac.uk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: uname: -i and -p options give unhelpful answers

Date: Tue, 13 May 2003 13:01:21 +0100

Package: coreutils
Version: 5.0-1
Severity: normal

According to the manual, uname has the following options:

`-i'
`--hardware-platform'
     Print the hardware platform name (sometimes called the hardware
     implementation).

`-p'
`--processor'
     Print the processor type (sometimes called the instruction set
     architecture or ISA).

On my system, though, both of them return "unknown".  This is less than
useful.  I'm not sure what "uname -i" should do on a PC, but "uname -p"
should return something like "i386", which I suspect could be set at compile
time if there turns out to be no way to get it out of the kernel.

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux wraith 2.4.20 #2 Wed Jan 22 16:53:10 GMT 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages coreutils depends on:
ii  libc6                         2.3.1-16   GNU C Library: Shared libraries an

Message #10 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Ben Harris <bjh21@cam.ac.uk>, 193170@bugs.debian.org

Subject: Re: Bug#193170: uname: -i and -p options give unhelpful answers

Date: Tue, 13 May 2003 08:42:12 -0400

On Tue, May 13, 2003 at 01:01:21PM +0100, Ben Harris wrote:
>On my system, though, both of them return "unknown".  This is less than
>useful.  I'm not sure what "uname -i" should do on a PC, but "uname -p"
>should return something like "i386", which I suspect could be set at compile
>time if there turns out to be no way to get it out of the kernel.

Not a coreutils issue.  The output from uname comes directly from the
uname(2) system call; it is not the job of uname(1) to do further
interpretation. I'd reassign this but no other package seems willing to
accept it, so I'm closing it.

Mike Stone

Message #15 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Ben Harris <bjh21@cam.ac.uk>

To: Michael Stone <mstone@debian.org>

Cc: 193170@bugs.debian.org

Subject: Re: Bug#193170: uname: -i and -p options give unhelpful answers

Date: Tue, 13 May 2003 15:52:33 +0100 (BST)

On Tue, 13 May 2003, Michael Stone wrote:

> On Tue, May 13, 2003 at 01:01:21PM +0100, Ben Harris wrote:
> >On my system, though, both of them return "unknown".  This is less than
> >useful.  I'm not sure what "uname -i" should do on a PC, but "uname -p"
> >should return something like "i386", which I suspect could be set at compile
> >time if there turns out to be no way to get it out of the kernel.
>
> Not a coreutils issue.  The output from uname comes directly from the
> uname(2) system call;

This is not true of the -i, -p and -o options.  For -i and -p, uname
(lines 240--285 of src/uname.c) uses either sysinfo() or sysctl(), but in
the case of a Linux host seems to use neither.  For -o, uname has a
constant string compiled in.  As far as I can see, the relevant code,
after preprocessing and stripping blank lines, looks like:

  if (toprint & 32)
    {
      char const *element = unknown;
      print_element (element);
    }
  if (toprint & 64)
    {
      char const *element = unknown;
      print_element (element);
    }
  if (toprint & 128)
    print_element ("GNU/Linux");
  putchar_unlocked ('\n');

"unknown" is defined as:

  static char const unknown[] = "unknown";

I think this code could do something more useful, if only to return the
compile-time Debian architecture string or similar.  Even rejecting -i and
-p would be better than the current behaviour.

-- 
Ben Harris

Message #20 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Jim Meyering <jim@meyering.net>

To: Ben Harris <bjh21@cam.ac.uk>

Cc: 193170@bugs.debian.org, Michael Stone <mstone@debian.org>

Subject: Re: Bug#193170: uname: -i and -p options give unhelpful answers

Date: Tue, 13 May 2003 17:22:01 +0200

Ben Harris <bjh21@cam.ac.uk> wrote:
...
>> Not a coreutils issue.  The output from uname comes directly from the
>> uname(2) system call;
>
> This is not true of the -i, -p and -o options.  For -i and -p, uname
> (lines 240--285 of src/uname.c) uses either sysinfo() or sysctl(), but in
> the case of a Linux host seems to use neither.  For -o, uname has a
> constant string compiled in.  As far as I can see, the relevant code,
> after preprocessing and stripping blank lines, looks like:

The point is that the information comes from the kernel --
via uname or some other method.

Message #25 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Ben Harris <bjh21@cam.ac.uk>

To: Jim Meyering <jim@meyering.net>

Cc: 193170@bugs.debian.org, Michael Stone <mstone@debian.org>

Subject: Re: Bug#193170: uname: -i and -p options give unhelpful answers

Date: Tue, 13 May 2003 16:46:39 +0100 (BST)

On Tue, 13 May 2003, Jim Meyering wrote:

> Ben Harris <bjh21@cam.ac.uk> wrote:
> ...
> >> Not a coreutils issue.  The output from uname comes directly from the
> >> uname(2) system call;
> >
> > This is not true of the -i, -p and -o options.  For -i and -p, uname
> > (lines 240--285 of src/uname.c) uses either sysinfo() or sysctl(), but in
> > the case of a Linux host seems to use neither.  For -o, uname has a
> > constant string compiled in.  As far as I can see, the relevant code,
> > after preprocessing and stripping blank lines, looks like:
>
> The point is that the information comes from the kernel --
> via uname or some other method.

No it doesn't.  If Linux's <sys/sysctl.h> defined HW_MODEL or
HW_MACHINE_ARCH, or if it had <sys/systeminfo.h>, _then_ uname would get
the information from the kernel.  But Linux doesn't have these:

wraith:/usr/include$ ls sys/systeminfo.h
ls: sys/systeminfo.h: No such file or directory
wraith:/usr/include$ find . | xargs grep HW_MODEL
wraith:/usr/include$ find . | xargs grep HW_MACHINE_ARCH
wraith:/usr/include$

uname.c detects this fact at compile time, and falls back to returning the
compile-time constant string "unknown".

-- 
Ben Harris

Message #30 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Jim Meyering <jim@meyering.net>

To: Ben Harris <bjh21@cam.ac.uk>

Cc: 193170@bugs.debian.org, Michael Stone <mstone@debian.org>

Subject: Re: Bug#193170: uname: -i and -p options give unhelpful answers

Date: Tue, 13 May 2003 17:54:33 +0200

Ben Harris <bjh21@cam.ac.uk> wrote:
> On Tue, 13 May 2003, Jim Meyering wrote:
>
>> Ben Harris <bjh21@cam.ac.uk> wrote:
>> ...
>> >> Not a coreutils issue.  The output from uname comes directly from the
>> >> uname(2) system call;
>> >
>> > This is not true of the -i, -p and -o options.  For -i and -p, uname
>> > (lines 240--285 of src/uname.c) uses either sysinfo() or sysctl(), but in
>> > the case of a Linux host seems to use neither.  For -o, uname has a
>> > constant string compiled in.  As far as I can see, the relevant code,
>> > after preprocessing and stripping blank lines, looks like:
>>
>> The point is that the information comes from the kernel --
>> via uname or some other method.
>
> No it doesn't.  If Linux's <sys/sysctl.h> defined HW_MODEL or
> HW_MACHINE_ARCH, or if it had <sys/systeminfo.h>, _then_ uname would get
> the information from the kernel.  But Linux doesn't have these:
>
> wraith:/usr/include$ ls sys/systeminfo.h
> ls: sys/systeminfo.h: No such file or directory
> wraith:/usr/include$ find . | xargs grep HW_MODEL
> wraith:/usr/include$ find . | xargs grep HW_MACHINE_ARCH
> wraith:/usr/include$
>
> uname.c detects this fact at compile time, and falls back to returning the
> compile-time constant string "unknown".

????
Well, of course, the string, "unknown", doesn't come from the kernel.
Please assume I have read the source as well :-)

When reporting anything other than `unknown', uname uses information
from one of those interfaces to the kernel.

Message #35 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Ben Harris <bjh21@cam.ac.uk>

To: Jim Meyering <jim@meyering.net>

Cc: 193170@bugs.debian.org, Michael Stone <mstone@debian.org>

Subject: Re: Bug#193170: uname: -i and -p options give unhelpful answers

Date: Tue, 13 May 2003 17:44:59 +0100 (BST)

On Tue, 13 May 2003, Jim Meyering wrote:

> When reporting anything other than `unknown', uname uses information
> from one of those interfaces to the kernel.

... and you're unwilling for it to use anything other than kernel
interfaces, yes?

<FX: checks>  Urgh, and while $(ARCH) during the Linux kernel build is
more-or-less precisely what "uname -p" should output, you can't get it out
of the kernel because the only place it ends up in the kernel is in
system_utsname.machine, and that gets patched at boot time based on the
type of CPU in the system.  Yuck.  Please feel free to blame it on the
kernel and close this bug.  I'll make my script spot "unknown" and do
something useful with it.

-- 
Ben Harris

Message #40 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Ben Harris <bjh21@cam.ac.uk>

Cc: Jim Meyering <jim@meyering.net>, 193170@bugs.debian.org

Subject: Re: Bug#193170: uname: -i and -p options give unhelpful answers

Date: Tue, 13 May 2003 13:25:53 -0400

On Tue, May 13, 2003 at 04:46:39PM +0100, Ben Harris wrote:
>No it doesn't.  If Linux's <sys/sysctl.h> defined HW_MODEL or
>HW_MACHINE_ARCH, or if it had <sys/systeminfo.h>, _then_ uname would get
>the information from the kernel.  But Linux doesn't have these:

Yes, that's the problem. There's no interface for uname to get better
values then "unknown". The info kinda-sort exists in /proc, but in a
different format for every architecture and with no guarantees about
cross-version compatability.

Mike Stone

Message #45 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 193170@bugs.debian.org

Subject: uname: missing documented flags

Date: Tue, 18 Nov 2003 14:37:33 -0800

Hi #19317,

The uname -p and -i flags aren't supported using the latest coreutils in 
unstable. Here's a console script,

-----------------------------------------------------------------------
Script started on Tue Nov 18 11:36:23 2003
taggart@cyrix:~ $ uname -p
Try `uname --help' for more information.
taggart@cyrix:~ $ uname --processor
uname: unrecognized option `--processor'
Try `uname --help' for more information.
taggart@cyrix:~ $ uname -i
Try `uname --help' for more information.
taggart@cyrix:~ $ uname --hardware-platform
uname: unrecognized option `--hardware-platform'
Try `uname --help' for more information.
taggart@cyrix:~ $ uname --help
Usage: uname [OPTION]...
Print certain system information.  With no OPTION, same as -s.

  -a, --all                print all information, in the following order:
  -s, --kernel-name        print the kernel name
  -n, --nodename           print the network node hostname
  -r, --kernel-release     print the kernel release
  -v, --kernel-version     print the kernel version
  -m, --machine            print the machine hardware name
  -o, --operating-system   print the operating system
      --help     display this help and exit
      --version  output version information and exit

Report bugs to <bug-coreutils@gnu.org>.
taggart@cyrix:~ $ dpkg -l coreutils
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  coreutils      5.0.91-2       The GNU core utilities
taggart@cyrix:~ $ which uname
/bin/uname
taggart@cyrix:~ $ file /bin/uname
/bin/uname: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
taggart@cyrix:~ $ md5sum /bin/uname
b5bbe6c57fcb0e288c93fd475648f6e5  /bin/uname
taggart@cyrix:~ $ exit
exit

Script done on Tue Nov 18 11:39:00 2003
-----------------------------------------------------------------------

However the uname info entry lists,
-----------------------------------------------------------------------
`-i'
`--hardware-platform'
     Print the hardware platform name (sometimes called the hardware
     implementation).

`-p'
`--processor'
     Print the processor type (sometimes called the instruction set
     architecture or ISA).
-----------------------------------------------------------------------

Others in this thread report uname returning the string "unknown" for
for these flags.

Am I doing something wrong? Can someone confirm what I'm seeing?

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #50 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Matt Taggart <taggart@debian.org>

To: 193170@bugs.debian.org, 193702@bugs.debian.org

Subject: uname info page problem and Why?

Date: Tue, 18 Nov 2003 15:08:02 -0800

I guess my previous mail to #193170 is covered by #193702. Sorry
about that.

I'm still not clear why these flags were removed. I realize they have
little value, but they're still supported on RedHat and SuSE. Are they
being removed from upstream?
If so then maybe the Debian changelog could have said so.
If not then why are we diverging? Convince upstream first.

Thanks,

-- 
Matt Taggart
taggart@debian.org

Message #55 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Martin Michlmayr <tbm@cyrius.com>

To: Matt Taggart <taggart@debian.org>, 193170@bugs.debian.org

Cc: 193702@bugs.debian.org

Subject: Re: Bug#193170: uname info page problem and Why?

Date: Wed, 19 Nov 2003 12:16:10 +1100

* Matt Taggart <taggart@debian.org> [2003-11-18 15:08]:
> I'm still not clear why these flags were removed. I realize they have
> little value, but they're still supported on RedHat and SuSE. Are they
> being removed from upstream?
> If so then maybe the Debian changelog could have said so.
> If not then why are we diverging? Convince upstream first.

They are removed in a Debian specific patch,

coreutils (5.0-3) unstable; urgency=low

  * More hurd stuff, again (Closes: 190738)
  * uname -i and -p don't exist anymore, stop complaining

 -- Michael Stone <mstone@debian.org>  Tue, 13 May 2003 16:57:55 -0400

Upstream introduced -i and -p but many users complained that it wasn't
reliable and so Mike disabled it.

I agree that -i and -p should work since they work on other systems,
and just display "unknown" or something.  FWIW, this has caused a bug
in ion-devel recently which calls "uname -p".

-- 
Martin Michlmayr
tbm@cyrius.com

Message #60 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Martin Michlmayr <tbm@cyrius.com>, 193702@bugs.debian.org

Cc: Matt Taggart <taggart@debian.org>, 193170@bugs.debian.org

Subject: Re: Bug#193702: Bug#193170: uname info page problem and Why?

Date: Tue, 18 Nov 2003 21:52:42 -0500

On Wed, Nov 19, 2003 at 12:16:10PM +1100, Martin Michlmayr wrote:
>Upstream introduced -i and -p but many users complained that it wasn't
>reliable and so Mike disabled it.

It's a nonstandard flag anyway that never should have been added, IMHO.
Neither existed in the woody version of uname, and any program that
assumes that they're there is broken anyway. I got tired of people
complaining that uname reported "unknown" instead of their particular
processor type. There's no reliable mechanism for querying that
information from the kernel. I'd rather diverge from upstream by
dropping this whole silly mess than by adding a pile of fragile code to
replace "unknown" with something useful. This is not open for further
discussion unless and until someone wants to document a reliable
interface for making uname report something more useful than "unkown".

Mike Stone

Message #65 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Damien Laniel <heretik@tuxfamily.org>

To: Debian Bug Tracking System <193170@bugs.debian.org>

Subject: coreutils: Remove -i and -p options from manual

Date: Fri, 15 Apr 2005 18:09:50 +0200

Package: coreutils
Version: 5.2.1-2
Followup-For: Bug #193170


As your decision has been to not support -i and -p flags, please remove them
from the man/infos pages


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-686
Locale: LANG=fr_FR.UTF-8@euro, LC_CTYPE=fr_FR.UTF-8@euro (charmap=UTF-8)

Versions of packages coreutils depends on:
ii  libacl1                     2.2.29-1.0.1 Access control list shared library
ii  libc6                       2.3.2.ds1-20 GNU C Library: Shared libraries an

-- no debconf information

Message #70 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Kalle Olavi Niemitalo <kon@iki.fi>

To: Debian Bug Tracking System <193170@bugs.debian.org>

Cc: Damien Laniel <heretik@tuxfamily.org>

Subject: Re: coreutils: Remove -i and -p options from manual

Date: Sat, 30 Apr 2005 13:04:47 +0300

[Message part 1 (text/plain, inline)]

Damien Laniel <heretik@tuxfamily.org> writes:

> As your decision has been to not support -i and -p flags, please remove them
> from the man/infos pages

In coreutils 5.2.1-2, the -i and -p flags are not listed in the
uname man page, which is mostly generated from the --help output.
Removing them from Info may be too much work, because of section
4 of the GFDL.  (/usr/share/doc/coreutils/copyright mentions
"removal of the doc/ subdirectory"; what's that?)

However, I think something should still be changed.  Currently,
uname -p or -i does not give the same error message as other
unsupported options:

kalle@Astalo:~$ uname --processor
uname: unrecognized option `--processor'
Try `uname --help' for more information.
kalle@Astalo:~$ uname -Z
uname: invalid option -- Z
Try `uname --help' for more information.
kalle@Astalo:~$ uname -p
Try `uname --help' for more information.

This happens because "p" and "i" are still present in the string
of supported options that uname.c gives to getopt_long.  The
attached patch fixes that.

[coreutils_5.2.1-2_193170.diff (text/x-patch, attachment)]

[Message part 3 (application/pgp-signature, inline)]

Message #75 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Paul Eggert <eggert@CS.UCLA.EDU>

To: bug-coreutils@gnu.org

Cc: bob@proulx.com (Bob Proulx), ams@gnu.org, 193170@bugs.debian.org, 193702@bugs.debian.org

Subject: Re: Possible bug in uname command

Date: Thu, 15 Sep 2005 13:05:29 -0700

While looking into this problem I noticed that Debian tried to disable
uname -p and -i, but they didn't do it quite right.  For example:

   $ /bin/uname -x
   /bin/uname: invalid option -- x
   Try `/bin/uname --help' for more information.
   $ /bin/uname -p
   Try `/bin/uname --help' for more information.

I checked the Debian bug database, and found that this is bug 193170
(see the mail from Kalle Olavi Niemitalo dated 2005-04-30).
I'll CC: this message to Debian, since I just installed a patch to
fix this bug along with everything else (please see below).


"Alfred M\. Szmidt" <ams@gnu.org> writes:

> How about those [uname -p and -i] options get disabled if
> POSIXLY_CORRECT is defined instead?

I'd rather not do that, since we want to minimize the effects of
POSIXLY_CORRECT.  POSIX does not require that these options be
disabled (or enabled, for that matter), so POSIXLY_CORRECT should not
affect uname's behavior when presented with those options.

I think you and Bob Proulx are both right, to some extent.  GNU/Linux
users have rebelled against having "uname -a" output "unknown" all the
time, so we should fix this.  However, it's certainly OK if "uname -p"
outputs "unknown".

Bob Proulx's idea of reporting -p and -i as invalid options if the
values are unknown would be a bit tricky, since in general we don't
know they're invalid unless we try to get the values.

So, instead, I propose that uname -a not output the -i and -p
information if it is unavailable.  That'll make uname -a output harder
to parse, but it's already impossible to parse portably anyway, so
it's no big deal.  It does address the issue that Debian rebelled
over.  And it won't break any scripts in practice (unless they're
unportable or broken anyway).

I installed the following patch to implement this.  Comments are
welcome.  I wish the problem would go away, but it won't....

2005-09-15  Paul Eggert  <eggert@cs.ucla.edu>

	* NEWS: uname -a no longer generates the -p and -i outputs if they
	are unknown.
	* doc/coreutils.texi (uname invocation): Document this.
	* src/uname.c (usage): Document this.
	(main): Implement this.

Index: NEWS
===================================================================
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.310
diff -p -u -r1.310 NEWS
--- NEWS	14 Sep 2005 06:57:35 -0000	1.310
+++ NEWS	15 Sep 2005 19:55:38 -0000
@@ -210,6 +210,8 @@ GNU coreutils NEWS                      
   stat -f's default output format has been changed to output this size as well.
   stat -f recognizes file systems of type XFS and JFS
 
+  uname -a no longer generates the -p and -i outputs if they are unknown.
+
 * Major changes in release 5.3.0 (2005-01-08) [unstable]
 
 ** Bug fixes
Index: doc/coreutils.texi
===================================================================
RCS file: /fetish/cu/doc/coreutils.texi,v
retrieving revision 1.282
diff -p -u -r1.282 coreutils.texi
--- doc/coreutils.texi	13 Sep 2005 23:01:59 -0000	1.282
+++ doc/coreutils.texi	15 Sep 2005 19:55:41 -0000
@@ -12214,7 +12214,8 @@ The program accepts the following option
 @itemx --all
 @opindex -a
 @opindex --all
-Print all of the below information.
+Print all of the below information, except omit the processor type
+and the hardware platform name if they are unknown.
 
 @item -i
 @itemx --hardware-platform
Index: src/uname.c
===================================================================
RCS file: /fetish/cu/src/uname.c,v
retrieving revision 1.66
diff -p -u -r1.66 uname.c
--- src/uname.c	14 May 2005 07:58:37 -0000	1.66
+++ src/uname.c	15 Sep 2005 19:55:41 -0000
@@ -118,7 +118,8 @@ usage (int status)
       fputs (_("\
 Print certain system information.  With no OPTION, same as -s.\n\
 \n\
-  -a, --all                print all information, in the following order:\n\
+  -a, --all                print all information, in the following order,\n\
+                             except omit -p and -i if unknown:\n\
   -s, --kernel-name        print the kernel name\n\
   -n, --nodename           print the network node hostname\n\
   -r, --kernel-release     print the kernel release\n\
@@ -126,8 +127,8 @@ Print certain system information.  With 
       fputs (_("\
   -v, --kernel-version     print the kernel version\n\
   -m, --machine            print the machine hardware name\n\
-  -p, --processor          print the processor type\n\
-  -i, --hardware-platform  print the hardware platform\n\
+  -p, --processor          print the processor type or \"unknown\"\n\
+  -i, --hardware-platform  print the hardware platform or \"unknown\"\n\
   -o, --operating-system   print the operating system\n\
 "), stdout);
       fputs (HELP_OPTION_DESCRIPTION, stdout);
@@ -172,7 +173,7 @@ main (int argc, char **argv)
       switch (c)
 	{
 	case 'a':
-	  toprint = -1;
+	  toprint = UINT_MAX;
 	  break;
 
 	case 's':
@@ -286,7 +287,8 @@ main (int argc, char **argv)
 # endif
 	}
 #endif
-      print_element (element);
+      if (! (toprint == UINT_MAX && element == unknown))
+	print_element (element);
     }
 
   if (toprint & PRINT_HARDWARE_PLATFORM)
@@ -310,7 +312,8 @@ main (int argc, char **argv)
 	    element = hardware_platform;
 	}
 #endif
-      print_element (element);
+      if (! (toprint == UINT_MAX && element == unknown))
+	print_element (element);
     }
 
   if (toprint & PRINT_OPERATING_SYSTEM)

Message #80 received at 193170@bugs.debian.org (full text, mbox, reply):

From: "Alfred M\. Szmidt" <ams@gnu.org>

To: Paul Eggert <eggert@CS.UCLA.EDU>

Cc: bug-coreutils@gnu.org, bob@proulx.com, 193170@bugs.debian.org, 193702@bugs.debian.org

Subject: Re: Possible bug in uname command

Date: Thu, 15 Sep 2005 22:25:37 +0200

I like the fix.  Though, changing the behaviour of `uname -a' just
cause some people have rebelled against it outputing `unknown' in some
places is quite silly; why not add such support to Linux and have it
output something useful!

Thanks Paul.

Message #85 received at 193170-done@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 193170-done@bugs.debian.org

Subject: uname -i and -p

Date: Sun, 13 Nov 2005 07:38:35 -0500

Version: 5.93-1

uname -i and -p are back, because uname -a no longer blows past 80
characters to print "unknown unknown". The individual options -i & -p
still print unknown. That won't change unless it changes upstream, so
I'm closing the bug.

Mike Stone

Message #90 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Steffen Grunewald <steffen.grunewald@aei.mpg.de>

To: Debian Bug Tracking System <193170@bugs.debian.org>

Subject: coreutils: 5.97-5.3 (Etch) still has the "uname -p" problem

Date: Mon, 25 Jun 2007 09:04:29 +0200

Package: coreutils
Version: 5.97-5.3
Followup-For: Bug #193170

Although #193170 has been marked FIXED, the Etch version still returns "unknown"
for "uname -p" - both on a 32bit i686 "uname -m" and a 64bit x86_64.
Recent Globus (www.globus.org) build scripts check for the output of "uname -p"
(or Python's platform.processor() which is based on that value) to determine
the platform the build is intented for, resulting in an incorrect build (mixed
32/64 bit or failure).
While replacing "uname -p" with "uname -m" and "platform.processor()" with
"platform.machine()" would be a workaround, this is not suitable if the Globus
build is embedded in another bigger environment (like VDT, vdt.cs.wisc.edu).


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages coreutils depends on:
ii  libacl1                     2.2.41-1     Access control list shared library
ii  libc6                       2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libselinux1                 1.32-3       SELinux shared libraries

coreutils recommends no packages.

-- no debconf information

Message #95 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Steffen Grunewald <steffen.grunewald@aei.mpg.de>, 193170@bugs.debian.org

Subject: Re: Bug#193170: coreutils: 5.97-5.3 (Etch) still has the "uname -p" problem

Date: Mon, 25 Jun 2007 11:11:06 -0400

On Mon, Jun 25, 2007 at 09:04:29AM +0200, you wrote:
>Recent Globus (www.globus.org) build scripts check for the output of "uname -p"
>(or Python's platform.processor() which is based on that value) to determine
>the platform the build is intented for, resulting in an incorrect build (mixed
>32/64 bit or failure).

Well, that's a mistake on their part, assuming distribution-specific 
output from a standard tool. 

Mike Stone

Message #100 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Steffen Grunewald <steffen.grunewald@aei.mpg.de>

To: Michael Stone <mstone@debian.org>

Cc: 193170@bugs.debian.org

Subject: Re: Bug#193170: coreutils: 5.97-5.3 (Etch) still has the "uname -p" problem

Date: Tue, 26 Jun 2007 08:26:37 +0200

On Mon, Jun 25, 2007 at 11:11:06AM -0400, Michael Stone wrote:
> On Mon, Jun 25, 2007 at 09:04:29AM +0200, you wrote:
> >Recent Globus (www.globus.org) build scripts check for the output of 
> >"uname -p"
> >(or Python's platform.processor() which is based on that value) to 
> >determine
> >the platform the build is intented for, resulting in an incorrect build 
> >(mixed
> >32/64 bit or failure).
> 
> Well, that's a mistake on their part, assuming distribution-specific 
> output from a standard tool. 

well, it might be. But the result is that under Debian the installation
fails while it works with RH, Fedora, ... you name it. Debian seems to 
be the only distro that returns "unknown" when queried for the processor
type. This is embarassing ... it should be easy to return the same value
as for machine type, isn't it? (Virtually every other distro I checked
does this, and lacking more information, that seems reasonable to me.)

Hmmm, looks like I have to go and patch up my own uname :-(

Steffen

-- 
Steffen Grunewald * MPI Grav.Phys.(AEI) * Am Mühlenberg 1, D-14476 Potsdam
Cluster Admin * http://pandora.aei.mpg.de/merlin/ * http://www.aei.mpg.de/
* e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
No Word/PPT mails - http://www.gnu.org/philosophy/no-word-attachments.html

Message #105 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Steffen Grunewald <steffen.grunewald@aei.mpg.de>

Cc: 193170@bugs.debian.org

Subject: Re: Bug#193170: coreutils: 5.97-5.3 (Etch) still has the "uname -p" problem

Date: Tue, 26 Jun 2007 07:21:00 -0400

On Tue, Jun 26, 2007 at 08:26:37AM +0200, Steffen Grunewald wrote:
>On Mon, Jun 25, 2007 at 11:11:06AM -0400, Michael Stone wrote:
>> Well, that's a mistake on their part, assuming distribution-specific 
>> output from a standard tool. 
>
>well, it might be. But the result is that under Debian the installation
>fails while it works with RH, Fedora, ... you name it.

hmm. Is there any chance that the installation script was *designed* to 
work on those distributions? (I note that you list two redhat 
variants...what does slackware do, for example?)

> Debian seems to 
>be the only distro that returns "unknown" when queried for the processor
>type. This is embarassing ... it should be easy to return the same value
>as for machine type, isn't it? 

That would be incorrect; the details are in the bug log. If the machine 
type were what you were looking for, why not just use uname -m? (And 
forward that suggestion upstream.) If you look at the posix standard for 
uname, there is no such thing as a -i or a -p: 
http://www.opengroup.org/onlinepubs/009695399/utilities/uname.html
On openbsd, e.g., you'll get nothing for uname -i and a long text string 
for uname -p. I'm fairly certain that redhat used to return something 
long and hideous for uname -p as well, so I wouldn't rely on any 
particular output from a non-standardized option.

Mike Stone

Message #110 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Steffen Grunewald <steffen.grunewald@aei.mpg.de>

To: Michael Stone <mstone@debian.org>

Cc: 193170@bugs.debian.org

Subject: Re: Bug#193170: coreutils: 5.97-5.3 (Etch) still has the "uname -p" problem

Date: Tue, 26 Jun 2007 14:09:07 +0200

On Tue, Jun 26, 2007 at 07:21:00AM -0400, Michael Stone wrote:
> On Tue, Jun 26, 2007 at 08:26:37AM +0200, Steffen Grunewald wrote:
> >On Mon, Jun 25, 2007 at 11:11:06AM -0400, Michael Stone wrote:
> >>Well, that's a mistake on their part, assuming distribution-specific 
> >>output from a standard tool. 
> >
> >well, it might be. But the result is that under Debian the installation
> >fails while it works with RH, Fedora, ... you name it.
> 
> hmm. Is there any chance that the installation script was *designed* to 
> work on those distributions? (I note that you list two redhat 
> variants...what does slackware do, for example?)
> 
> >Debian seems to 
> >be the only distro that returns "unknown" when queried for the processor
> >type. This is embarassing ... it should be easy to return the same value
> >as for machine type, isn't it? 
> 
> That would be incorrect; the details are in the bug log. If the machine 
> type were what you were looking for, why not just use uname -m? (And 
> forward that suggestion upstream.) If you look at the posix standard for 
> uname, there is no such thing as a -i or a -p: 
> http://www.opengroup.org/onlinepubs/009695399/utilities/uname.html
> On openbsd, e.g., you'll get nothing for uname -i and a long text string 
> for uname -p. I'm fairly certain that redhat used to return something 
> long and hideous for uname -p as well, so I wouldn't rely on any 
> particular output from a non-standardized option.

OK, I see the point to some amount at least. Still I'm wondering why
we do not fill in something more useful than "unknown" - the processor
type is not completely unknown to us admitted that this info is already
in the machine type.

Adding Fedora's (taken from FC6 source package) "coreutils-4.5.3-sysinfo.patch"
to the debian/patches directory produced the correct (in Globus' sense)
behaviour, so I will live with my own patched-up packages for now.

Steffen

Message #115 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Steffen Grunewald <steffen.grunewald@aei.mpg.de>

Cc: 193170@bugs.debian.org

Subject: Re: Bug#193170: coreutils: 5.97-5.3 (Etch) still has the "uname -p" problem

Date: Tue, 26 Jun 2007 08:25:11 -0400

On Tue, Jun 26, 2007 at 02:09:07PM +0200, Steffen Grunewald wrote:
>OK, I see the point to some amount at least. Still I'm wondering why
>we do not fill in something more useful than "unknown" - the processor
>type is not completely unknown to us admitted that this info is already
>in the machine type.

Because it's not uname's job to guess what you mean by processor type.  
The right answer is going to be something like "Geode by NSC" or 
"Intel(R) Pentium(R) III CPU - S 1400MHz". An openbsd system will say 
something like "AMD Am5x86 W/B 133/160 ("AuthenticAMD" 486-class)". 
"i686" is flat out the wrong answer for this question. The bigger 
question is *why* you would want to know this. The *right* answer in 
almost every case is that you want to use processor specific features 
(or you don't need to know this at all) and you should be checking 
processor feature flags (e.g., see the flags: line in /proc/cpuinfo) 
rather than guessing what features are supported based on the cpu type 
(because as soon as a new cpu comes along you won't know what it 
supports). Well written code will check those flags at run time.

Bottom line: the use of uname -p is almost certainly a mistake in 
whatever application is using it, regardless of what debian reports when 
that option is used.

Mike Stone

Message #120 received at 193170@bugs.debian.org (full text, mbox, reply):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>

To: 193170@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#193170: uname: -i and -p options give unhelpful answers

Date: Tue, 22 Jan 2008 21:49:33 +0100

reopen 193170
tags 193170 + wishlist wontfix
thanks

Hi,

This bug was closed, then marked as found in a later version. (see the
nice version graph).

Restoring it to a sane status.

Lucas

Message #131 received at 193170-close@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: 193170-close@bugs.debian.org

Subject: uname: -i and -p options give unhelpful answers

Date: Mon, 12 Sep 2011 14:01:00 -0400

This bug seems not to want to die, but what I said in the last message 
stands: code that wants this is doing something wrong. I suggest looking 
at the flags: section of /proc/cpuinfo if writing a shell script, or 
various runtime processor feature tests as appropriate. Nobody has 
proposed a use case for this in the past several years, so I hope the 
bug can stay closed this time.

Mike Stone

Send a report that this bug log contains spam.