On Thu, Mar 09, 2000 at 10:05:52PM -0500, Albert D. Cahalan wrote:
>
> Ville Herva writes:
> > On Thu, Mar 09, 2000 at 10:09:25AM -0500, you [Tim Coleman] claimed:
> >> On Wed, Mar 08, 2000 at 06:35:18PM +0200, Ville Herva wrote:
>
> >>> Perhaps "uname -a" in linux_ver script should changed to
> >>> "cat /proc/version"?
> >>
> >> Or maybe uname should be changed to include the compiler?
> >>
> >> Just a thought
> >
> > Sounds good unless there are some kind of unix standard issues on what
> > uname should return.
>
> 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:
> [...]
> -v build23_gcc2.7.2.3_date952640409_opt686smp
> [...]
That looks kind of gross. But quite informative at the same time.
> [...]
> 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.
Yes, I don't know why it doesn't come up with "ia32" for that.
> While it is legal to have spaces, normal systems would use '_' in
> the -v output or only have a single integer. [...]
I would consider linux to be a "normal system". :)
> 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.
I'm not sure it's uname's fault. I think it just reports whatever
it is given in the utsname structure. Whatever sets that (and I think
it may be the kernel itself) would be to blame if the information
was non-standard (whatever the standard actually is).
A good point that was raised is that we probably don't want to
mess around with the structure of the output to avoid breaking
shell scripts and such. Since the alternative would be a simple
change to the ver_linux script, I think we can do without a change
to the utsname information at the time being.
Here's a patch that would change the ver_linux script. If you
don't have a "/proc/version", it uses uname instead (just in
case). I also added some horizontal lines to improve the
readability (especially important when /proc/version spews
a lot of information).
-8<--------------------------------------------------------------
--- ver_linux Fri Mar 10 07:51:23 2000
+++ ver_linux_new Fri Mar 10 07:53:58 2000
@@ -7,7 +7,15 @@
PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH
echo '-- Versions installed: (if some fields are empty or look'
echo '-- unusual then possibly you have very old versions)'
-uname -a
+echo '------------------------------------------------------------------------'
+if [ -f "/proc/version" ]; then
+ echo 'System version (from /proc/version):'
+ cat /proc/version
+else
+ echo 'System version (from uname -a):'
+ uname -a
+fi
+echo '------------------------------------------------------------------------'
insmod -V 2>&1 | awk 'NR==1 {print "Kernel modules ",$NF}'
echo "Gnu C " `gcc --version`
ld -v 2>&1 | awk -F\) '{print $1}' | awk \
-8<--------------------------------------------------------------
Here's what the output would look like on my system:
$ sh ver_linux_new
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
------------------------------------------------------------------------
System version (from /proc/version):
Linux version 2.3.48 (root@beastor) (gcc version 2.95.2 19991103 (Debian
GNU/Linux)) #1 Thu Mar 2 12:42:54 EST 2000
------------------------------------------------------------------------
Kernel modules 2.3.9
Gnu C 2.95.2
Binutils 2.9.5.0.19
Linux C Library 2.1.3
Dynamic linker ldd: version 1.9.11
Procps 1.2.9
Mount 2.9g
Net-tools 2.01
Kbd 0.96
Sh-utils 1.16
Modules Loaded ipt_LOG ipt_tcp ip_nat_map_masquerade ip_nat
ipt_state iptables ip_conntrack_ftp ip_conntrack ppp_async ppp_generic
ne 8390 slhc eexpress smbfs cdu31a cdrom
Tim
-- ------------------------------------------------------------------------ tim@beastor.mine.nu Software Developer/Systems Administrator/RDBMS Specialist/Linux Advocate University of Waterloo Honours Co-op Combinatorics & Optimization finger tim@beastor.mine.nu for PGP public key ID 0xCB7C7974
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:17 EST