https://bugzilla.redhat.com/show_bug.cgi?id=2189656
God knows how many scripts I have that use "uname -p" to get the architecture name, but it now returns "unknown" instead of "x86_64".
I guess I'll replace uname with a script that invokes the real uname unless it is called with the -p option, then echoes x86_64 :-).
Tom Horsley wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=2189656
God knows how many scripts I have that use "uname -p" to get the architecture name, but it now returns "unknown" instead of "x86_64".
I guess I'll replace uname with a script that invokes the real uname unless it is called with the -p option, then echoes x86_64 :-).
It's not a bug. :)
A non-upstream patch was removed¹, which had kept the long-deprecated uname -i and -p options.
¹ https://src.fedoraproject.org/rpms/coreutils/c/cd953e1
`uname -m` is probably what you want to use in those scripts, if you were looking for x86_64 as the output.
On Tue, 2023-04-25 at 17:18 -0400, Todd Zullinger wrote:
Tom Horsley wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=2189656
God knows how many scripts I have that use "uname -p" to get the architecture name, but it now returns "unknown" instead of "x86_64".
I guess I'll replace uname with a script that invokes the real uname unless it is called with the -p option, then echoes x86_64 :- ).
It's not a bug. :)
A non-upstream patch was removed¹, which had kept the long-deprecated uname -i and -p options.
¹ https://src.fedoraproject.org/rpms/coreutils/c/cd953e1
`uname -m` is probably what you want to use in those scripts, if you were looking for x86_64 as the output.
The man page still has '-p' and '-i', so that's at least a documentation bug.
poc
Patrick O'Callaghan wrote:
The man page still has '-p' and '-i', so that's at least a documentation bug.
The options are still accepted. They just don't produce the same output they did with a non-upstream patch.
Changed output across a major release isn't all that unreasonable -- even if it may be annoying to anyone who has come to rely on that output. :)
Those options were marked as non-portable for many years (since 2015, according to the BZ referenced in the git commit which dropped the patch). Using them on non-Fedora systems would already be likely to produce different results.
Considering there is an option which provides the same output that has worked for many years:
s/uname -p/uname -m/
shouldn't be too much of an issue.
Whether they should be removed entirely from the code and docs is likely something to discuss with the upstream coreutils project.
Tom Horsley wrote:
On Tue, 25 Apr 2023 17:49:08 -0400 Todd Zullinger wrote:
s/uname -p/uname -m/shouldn't be too much of an issue.
Right, just have to locate the 47,321 scripts which have some variation of that command in them. No problem at all :-).
I have good news and bad news...
This may be an opportunity to notice that the decade's long deprecation of egrep now causes a warning to stderr too.
$ egrep . /etc/os-release >/dev/null egrep: warning: egrep is obsolescent; using grep -E
I wasn't sure I'd live to see the day that deprecation moved forward, but here it is. ;-)
One idea for tracking things down which aren't stored in a place which is reasonable to grep, is a uname script which overrides the default uname command, logs the usage of -i/-p and the calling script, then replaces it with -m and exec's the real uname. (Which may be just what you were already planning.)
On Tue, 25 Apr 2023 18:58:45 -0400 Todd Zullinger wrote:
One idea for tracking things down which aren't stored in a place which is reasonable to grep, is a uname script which overrides the default uname command
I was going to do that, but I found the old f37 uname command runs fine on f38, so I just replaced the f38 version (for now, I'll eventually need something that can survive a coreutils update :-).
On Tue, 2023-04-25 at 17:49 -0400, Todd Zullinger wrote:
Patrick O'Callaghan wrote:
The man page still has '-p' and '-i', so that's at least a documentation bug.
The options are still accepted. They just don't produce the same output they did with a non-upstream patch.
Changed output across a major release isn't all that unreasonable -- even if it may be annoying to anyone who has come to rely on that output. :)
Those options were marked as non-portable for many years (since 2015, according to the BZ referenced in the git commit which dropped the patch). Using them on non-Fedora systems would already be likely to produce different results.
Considering there is an option which provides the same output that has worked for many years:
s/uname -p/uname -m/
shouldn't be too much of an issue.
Whether they should be removed entirely from the code and docs is likely something to discuss with the upstream coreutils project.
I'd call this disingenuous. If the behaviour of the options has changed, the documentation should change to reflect that. Keeping or removing them is a separate issue.
poc
On Tue, Apr 25, 2023 at 5:18 PM Todd Zullinger tmz@pobox.com wrote:
Tom Horsley wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=2189656
God knows how many scripts I have that use "uname -p" to get the architecture name, but it now returns "unknown" instead of "x86_64".
I guess I'll replace uname with a script that invokes the real uname unless it is called with the -p option, then echoes x86_64 :-).
It's not a bug. :)
A non-upstream patch was removed¹, which had kept the long-deprecated uname -i and -p options.
uname (1) says -i and -p are valid options:
-p, --processor print the processor type (non-portable)
-i, --hardware-platform print the hardware platform (non-portable)
`uname -m` is probably what you want to use in those scripts, if you were looking for x86_64 as the output.
Jeff
Jeffrey Walton wrote:
On Tue, Apr 25, 2023 at 5:18 PM Todd Zullinger tmz@pobox.com wrote:
A non-upstream patch was removed¹, which had kept the long-deprecated uname -i and -p options.
uname (1) says -i and -p are valid options:
-p, --processor print the processor type (non-portable) -i, --hardware-platform print the hardware platform (non-portable)
They are valid options, but there is no longer a Fedora patch which made them report the same as `uname -m`. They now report 'unknown' which isn't terribly useful.
The solution is use `uname -m` (which has been the ideal option to use for some time -- it's only now exposed to Fedora users, who had been getting a downstream patch).
On 4/25/23 17:56, Todd Zullinger wrote:
Jeffrey Walton wrote:
On Tue, Apr 25, 2023 at 5:18 PM Todd Zullinger tmz@pobox.com wrote:
A non-upstream patch was removed¹, which had kept the long-deprecated uname -i and -p options.
uname (1) says -i and -p are valid options:
-p, --processor print the processor type (non-portable) -i, --hardware-platform print the hardware platform (non-portable)They are valid options, but there is no longer a Fedora patch which made them report the same as `uname -m`. They now report 'unknown' which isn't terribly useful.
The solution is use `uname -m` (which has been the ideal option to use for some time -- it's only now exposed to Fedora users, who had been getting a downstream patch).
An alternative to that, if you have to change your scripts, is to use the "arch" command:
$ arch x86_64
-
Jeffrey Walton -
Patrick O'Callaghan -
Richard England -
Todd Zullinger -
Tom Horsley