Lots of little shells scripts I have now no longer work because the -p opton on uname has changed. It will probably take months to locate every script that uses uname -p and change it to use uname -m instead. Please fix uname to work the way it always has. Reproducible: Always Steps to Reproduce: 1.uname -p 2.see it echo "unknown" 3. Actual Results: unknown Expected Results: x86_64
The man page for uname (1) says its a valid option: -p, --processor print the processor type (non-portable) -i, --hardware-platform print the hardware platform (non-portable)
It was a mistake that a Fedora package maintainer added the downstream-only patch more than 20 years ago. All the scripts that relied on the behavior were non-portable. If we did not remove the patch now, people would continue to write new non-portable scripts. I understand how annoying it is to fix the technical debt that accumulated over the years but it needs to be done. Otherwise the annoyance would only grow in the future because there is no chance that upstream would adopt the patch. *** This bug has been marked as a duplicate of bug 2126206 ***
(In reply to Kamil Dudka from comment #2) > ... If we did not remove the patch now, people would > continue to write new non-portable scripts... So what? How is this relevant to supporting the documented options? What interest does Linux have in ensuring correctness on other operating systems like Solaris or Windows?
(In reply to Jeffrey Walton from comment #3) > So what? How is this relevant to supporting the documented options? The options have been documented as non-portable since 2015: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-7-g6d67649 Non-portable means they work differently (or not at all) on different systems. > What interest does Linux have in ensuring correctness on other operating > systems like Solaris or Windows? In this case, the options did not work portably even on Linux. They only worked on Fedora and its derivatives.
For example, if I run `uname -p` on my Gentoo Linux box, I get: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz Would your scripts work on such a system?
> They only worked on Fedora and its derivatives. Well, then Ubuntu, Slackware, and openSUSE count as Fedora derivatives? Here's the results that I get for `uname --version` and `uname -mip` on several machines: x86 === Slackware 14 8.19 i686 AMD Ryzen 7 4800U with Radeon Graphics AuthenticAMD Ubuntu 18.04 8.28 i686 athlon i686 x86_64 ====== CentOS 7 8.22 x86_64 x86_64 x86_64 openSUSE 15.2 8.29 x86_64 x86_64 x86_64 Ubuntu 22.04 8.32 x86_64 x86_64 x86_64 Fedora 36 9.0 x86_64 x86_64 x86_64 Arch Linux 19.11 8.31 x86_64 unknown unknown Alpine Linux 3.17 BusyBox x86_64 unknown unknown coreutils upstream 8.32.251-7b0db x86_64 unknown unknown I would agree that on x86 the values were not very useful due to missing normalization (e.g. "AuthenticAMD" vs. "i686"), whereas on x86_64 they were not very useful because identical to `uname -m`. A program that really needs to know details about the processor is gmp-6.2.1/config.guess, and they don't use `uname -i` or `uname -p` for this purpose, but instead inspect the value of the cpuid instruction.
(In reply to Bruno Haible from comment #6) > > They only worked on Fedora and its derivatives. > Well, then Ubuntu, Slackware, and openSUSE count as Fedora derivatives? I meant that this very specific behavior was available only on Fedora and its derivatives. `uname -p` and `uname -i`, of course, work on many other distros in the sense that they return "something".