Re: uname blues
Laurent de Segur writes:
> - Regarding the uname -p returning unknown:
...
> I have decided to report this as a bug to bug-sh-utils@gnu.org. Is that
> the right thing to do? Your input is, as usual, greatly appreciated.
Last year I examined the UNIX standard and 3 implementations to see
what Linux ought to be doing for x86. I'll include that post below,
but first an example of proper uname output for a Mac:
-s Linux (or "Debian")
-n host.example.com
-r 2.4.42 (or "woody")
-v build23_gcc3.0.7_date952640409_opt74x0smpHIMEM
-m MPC7400
-p ppc (or "PowerPC")
-i Apple,G4-Cube
-d pre4
------------------
The standard is "The Single UNIX(R) Specification, Version 2".
It is a bit vague, so I also checked Solaris 7, IRIX 6.3, and
Digital UNIX 4.0 for extensions and interpretations.
It would be most correct to do this:
-s Linux (or "RedHat")
-n host.example.com
-r 2.2.11 (or "6.2" or "2.1")
-v build23_gcc2.7.2.3_date952640409_opt686smp
-m K6-2
-p ia32
-i Compaq,Presario-7360
-d pre4
In all cases, output should be in the order shown. That is, there
should be no command that could produce "2.2.11 Linux".
The -a option should produce the first 5 values: -snrvm
Option -i will surely often be UNKNOWN,UNKNOWN (vendor comma model)
The model name ought to use the '-' character as needed.
Note that option -m is "K6-2", not "i686". (but that isn't terrible)
Currently I get "unknown" for -p, even though "ia32" is obvious.
While it is legal to have spaces, normal systems would use '_' in
the -v output or only have a single integer. One could put any sort
of vendor-specific junk in this field. It might even be best to use
this for non-kernel data, such as libc and distribution version.
Considering what "uname" is actually used for, one could argue
that it should report about C library and distribution versions.
I get "GNU sh-utils" for who made my Linux uname command, so maybe
somebody could report this problem to RMS or whoever. I suppose it
is most important to fix -p and remove whitespace from -v.
Reply to: