GNU bug report logs - #13001
Reporting potential bug | uname -p and uname -i return unknown on Debian

Previous Next

Package: coreutils;

Reported by: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>

Date: Mon, 26 Nov 2012 09:33:02 UTC

Severity: normal

Merged with 15757, 21098

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>, Jim Meyering <jim <at> meyering.net>, 13001 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
Date: Mon, 26 Nov 2012 20:26:33 +0000
On 11/26/2012 06:51 PM, Mike Frysinger wrote:
> On Mon, Nov 26, 2012 at 1:11 PM, Mike Frysinger wrote:
>> the GNU version relies on the standard
>> interfaces to do that (which they don't).
>
> to be clearer, the interfaces coreutils relies on don't exist on
> Linux, so it always issues "unknown"
>
>> you can find the patch i've been keeping up-to-date in Gentoo:
>> http://sources.gentoo.org/gentoo/src/patchsets/coreutils/8.20/003_all_coreutils-gentoo-uname.patch
>
> in the past, i assumed this wasn't going anyways because coreutils did
> not include any target-specific logic.  but i see it has since grown
> __APPLE__ support, so maybe i can make a case for adding __linux__.
>
> Paul: you were against this in the past [1], but in light of
> 594d5064c950fa1d99a9eafbd357c5f46320d002, can we reconsider ?  i don't
> mind helping out with this particular can considering i'm going to be
> doing it anyways ... not to mention every distro is running into the
> same issue and patching it in their own unique/incomplete way.
> -mike
>
> [1] http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00063.html

We should either deprecate the options, or try
to standardise them a bit.

From POSIX we have
  -m  Write the name of the hardware type on which
      the system is running to standard output.

From BSD we have:
  -m  print the machine hardware name.
  -p  print the machine processor architecture name.
  $ uname -mp
  amd64 x86_64

From Fedora 15 we have:
  -m  print the machine hardware name.
  -p  print the processor type or "unknown"
  -i  print the hardware platform or "unknown"
  $ uname -mpi
  x86_64 x86_64 x86_64

From Solaris we have:
  -m  Prints the machine hardware name (class).
      Use of this option is discouraged. Use -p instead.
  -p  Prints the current host's ISA or processor type.
  -i  Prints the name of the platform.
  > uname -mpi
  sun4v sparc SUNW,SPARC-Enterprise-T5220

From Debian we have:
  $ uname -mpi
  x86_64 unknown unknown

From Gentoo we have:
  $ uname -m
  x86_64
  $ uname -p
  Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz
  $ uname -i
  GenuineIntel

So it's awkward to come up with something coherent
between them all. I'd be inclined to have -p print the "arch",
i.e. x86_64, and leave -i to print out the free form
info from /proc cpu info.

cheers,
Pádraig.




This bug report was last modified 9 years and 306 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.