Laurent de Segur writes: > - Regarding the uname -p returning unknown: ... > I have decided to report this as a bug to [EMAIL PROTECTED] 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.
