DJ Delorie <[email protected]> writes: > Collin Funk <[email protected]> writes: >>> Until then, uname offers and documents the option, it should try to >>> return *something* usable. >> >> Shouldn't that be the distribution's job to fix, then? They were added >> for Solaris compatibility and have only been useful on GNU/Linux because >> distributions patched them in ways that were not compatible with each >> other. > > That would be option #2, and let the distros add the option if they want. > > Besides, adding a fallback doesn't stop distros from patching it anyway > if they want a different output.
True. I try to avoid them needing to patch things. But maybe I overestimate how much effort it is and how much they care. >>> 2. Remove the option completely, and exit with a non-zero exit error if >>> the user tries to use it. > > My point is, if coreutils offers the option (it does), it should try to > make it useful (it doesn't on all platforms). Either remove the option, > or make it useful. Printing "unknown" is neither useful nor gives the > user a way to resolve it. At least print "-p will never give anything > useful, use -m instead" so when the user sees their error, they will > also see the solution. I generally agree. Unfortunately, it has existed that way for many years, which makes it hard to change. :( > Maybe you could check for platforms that report info, and #define that > option completely away if not? That would be quite atypical for coreutils. I thought we might have done it with --text in 'cksum', but I see now that we just hide it from --help when O_BINARY doesn't have any meaning. The program will still accept the flag. >>> 3. Return something reasonable and easy so people are happy. >> >> I think I see a different outcome from option 3, besides making people >> happy. > > I didn't say it was a good choice, just that they'd be happy. There is > nothing uname(1) can do that would both (1) work and (2) inform them > that they need to change their scripts. Ah, okay, my misunderstanding. >> By having 'uname -ip' return: >> >> x86_64 x86_64 >> >> Wouldn't we just be encouraging people to write scripts that aren't >> portable to RHEL 10 and decades of Debian releases, Gentoo, etc.? Why do >> that when 'uname -m' exists? > > That too. Hence I'm contemplating having glibc provide something that > is different and more specific, like "x86_64-v3/sse3/erm" or "i7-1234U". > > It's easier to convince the user if their script is breaking because we > made the option *more* useful. > >> (*) I'm open to the idea. But I don't know how long the file has >> existed, or if it is guaranteed not to change its format. > > My idea is to use confstr() which is POSIX and has a > backwards-compatible way to detect if the option is available. glibc > works on more than Linux, and not all Linux containers have /proc > mounted anyway. That sounds like a good idea to me. glibc needs to keep track of CPUID values (or whatever the equivalent is for non-x86) anyway for choosing string.h functions and such, so it doesn't need /proc/cpuinfo to figure that out. Collin
