ver_linux script updates

ver_linux script updates

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

I've been working on an update to the ver_linux script and I'm looking 
for comment and help in improving the accuracy of reported information.

The script is at http://stuph.org/ver_linux

Please provide feedback on it.

Thanks,
-d


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3254 bytes --]

Re: ver_linux script updates

[Roberto Nibali]

Hello,

David Ford wrote:
> I've been working on an update to the ver_linux script and I'm looking 
> for comment and help in improving the accuracy of reported information.
> The script is at http://stuph.org/ver_linux
> 
> Please provide feedback on it.

o your script assumes bash as /bin/sh. Is this ok with everyone? Is
   there noone running a Bourne shell only? printf and declare are not
   in the standard Boune shell, IIRC.
o the script hangs when calling loadkeys, because loadkeys without
   arguments waits forever. A fix is to pass "loadkeys -V" as third
   argument to pv().
o if you assume bash why don't you try to convert all of the code into
   bash (inline functions) instead of using awk and sed like the old code
   did?
o your script indicates that one should check for "not found/error" but
   this never appears, it should be "error getting version, try manually"
o the old script separated the loaded kernel modules with a space, the
   new code with a '\n'
o the old code correctly detects my "kbd" version, the new not, because
   you use setleds which on my machine reports: "KDGKBLED: Invalid
   argument"

Why do you want to change this tool? To me it seems like an endless task 
because people don't code according to standards. For example if 
everyone could stick to let's say that 'progname --version' prints the 
version, things would be a lot easier.

Cheers,
Roberto Nibali, ratz

Re: ver_linux script updates

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]

> o your script assumes bash as /bin/sh. Is this ok with everyone? Is
>   there noone running a Bourne shell only? printf and declare are not
>   in the standard Boune shell, IIRC. 


printf can be changed, declare can be changed. Ideas for agnostic 
functions would be appreciated.

> o the script hangs when calling loadkeys, because loadkeys without
>   arguments waits forever. A fix is to pass "loadkeys -V" as third
>   argument to pv(). 

Not acceptable, perhaps --junkoption will suffice

> o if you assume bash why don't you try to convert all of the code into
>   bash (inline functions) instead of using awk and sed like the old code
>   did? 

Because I'm not a bash guru and I'm trying to keep it as simple.

> o your script indicates that one should check for "not found/error" but
>   this never appears, it should be "error getting version, try manually" 

Fixed, thank you

> o the old script separated the loaded kernel modules with a space, the
>   new code with a '\n' 

Will be fixed, thank you

> o the old code correctly detects my "kbd" version, the new not, because
>   you use setleds which on my machine reports: "KDGKBLED: Invalid
>   argument" 

This is one of the two big problems with this script.  'kbd' and 
'console-tools'  are developed in parallel.  console-tools was forked 
from kbd when the console-tools author felt the kbd author wasn't being 
responsive or accepting updates to the kbd package.  Both kbd and 
console-tools vary significantly even within themselves as to version 
reporting.  I would like to get a large number of responses on this one 
to develop a more accurate reporting of both  kbd and console-tools.

> Why do you want to change this tool? To me it seems like an endless 
> task because people don't code according to standards. For example if 
> everyone could stick to let's say that 'progname --version' prints the 
> version, things would be a lot easier. 

Because it doesn't work as well as I want it to.  The previous writers 
of this script wrote it based on their choice of distribution and 
installed packages.  There has always been one or more strange outputs 
or breakage when I run it .  All of my software is compiled from 
original tarballs or cvs from the original author.  That means if the 
script doesn't detect it correctly, then the script is trying to detect 
a mutation of the original source, i.e. a package from a distribution.

This means that the script needs to evolve because different 
distributions are going to have differing results.

I strongly agree that "--version" woud make life pretty simple here, but 
unfortunately (i.e. kbd and console-tools).

In a side note, if anybody has a reliable way of getting pppd to 
-always- report the version number, please tell me.  To get it to fail, 
put some junk in /etc/ppp/options, i.e. a not currently existing modem 
device such as /dev/usb/acm/0.

Thank you for your feedback,
David


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3254 bytes --]

Re: ver_linux script updates

[Roberto Nibali]

Hi

> printf can be changed, declare can be changed. Ideas for agnostic 
> functions would be appreciated.

Not in sh, you need an ugly 'awk|sed' call to do the printf with 
formatstrings. And for the declare, you just drop it. Anyway, it is 
incomplete. Or you can decide to do it in bash, and leave the nice 
printf functionality and other gadgets.

>> o the script hangs when calling loadkeys, because loadkeys without
>>   arguments waits forever. A fix is to pass "loadkeys -V" as third
>>   argument to pv(). 
> 
> 
> Not acceptable, perhaps --junkoption will suffice

Well it does, but since this stupid loadkeys writes everything to stderr 
you need to parse the output again as follows (on my machine):

loadkeys --junkoption 2>&1 | head -2 | tail -1

This is so gross you could as well do a strings on all those broken 
binaries and maintain a table of offsets where to find the version string.

>> o if you assume bash why don't you try to convert all of the code into
>>   bash (inline functions) instead of using awk and sed like the old code
>>   did? 
> 
> 
> Because I'm not a bash guru and I'm trying to keep it as simple.

Well, I could help you (not a bash guru either) but the more I think 
about this the more I think it's like the attempt of ESR to make an 
autoconfigurator. Let's see if I get this correctly:

o I read ../Documentation/Changes and read that
   "This document is designed to provide a list of the minimum levels of
    software necessary to run the 2.4 kernels, ..."
   Why the hell do I need pppd to get a running 2.4.x kernel? I also do
   not need reiserfs tools because I decided to run ext3. Well and on my
   firewall I definitely don't need any pcmcia-cs package which isn't
   even completely merged into the main kernel.
o I ask myself: What exactly does this file want to tell people. I
   might be dumb but to run a kernel you need to be able to compile it,
   link it an install it (noone asks for lilo).
o OTOH, the original author mentions that this software list should be
   checked before one even considers a bug to be a real bug an not just
   some incompatibility with a wrong user space tool.
o I ask myself: How define the set of tools then? Shouldn't we for
   example include LVM or raid tools (as actually mentioned further
   down in the same file)?
o Why is this script still in the kernel tree? It is not mentioned
   anywhere and it doesn't work reliably.

The whole concept looks pretty broken to me, but then again I'm just a 
little fart that doesn't see the big picture.

> This is one of the two big problems with this script.  'kbd' and 
> 'console-tools'  are developed in parallel.  console-tools was forked 
> from kbd when the console-tools author felt the kbd author wasn't being 
> responsive or accepting updates to the kbd package.  Both kbd and 

I see, very intelligent.

> console-tools vary significantly even within themselves as to version 
> reporting.  I would like to get a large number of responses on this one 
> to develop a more accurate reporting of both  kbd and console-tools.

Mine is further up in this email.

> Because it doesn't work as well as I want it to.  The previous writers 
> of this script wrote it based on their choice of distribution and 
> installed packages.  There has always been one or more strange outputs 
> or breakage when I run it .  All of my software is compiled from 
> original tarballs or cvs from the original author.  That means if the 

I have such a distro too, I might run your version of the script on it 
as soon as I got some sleep.

> script doesn't detect it correctly, then the script is trying to detect 
> a mutation of the original source, i.e. a package from a distribution.

What if it hangs like in my example? I suggest you switch over to perl 
or if you want I can give you my bash-exec-alarm-signal handler I once 
wrote. But it's an extreme overkill to have such a thing built-in in 
your script.

> This means that the script needs to evolve because different 
> distributions are going to have differing results.

Good luck. I agree that certain information is important to have, such as:

o  Gnu C                  2.95.3                  # gcc --version
o  Gnu make               3.77                    # make --version
o  binutils               2.9.1.0.25              # ld -v
o  util-linux             2.10o                   # fdformat --version
o  modutils               2.4.2                   # insmod -V

I fail to see why I need more information from that script. But don't 
let yourself stop by my comments.

> I strongly agree that "--version" woud make life pretty simple here, but 
> unfortunately (i.e. kbd and console-tools).

I don't know how many tools I've already patched exactly because of this 
bloody annoyance. If one wants to build a stable, reliable, reproducable 
and secure box, where information can be get with simple scripts without 
thousands of lines of code for every little funny thing a programmer out 
there thought might be better than all other existing tools.

> In a side note, if anybody has a reliable way of getting pppd to 
> -always- report the version number, please tell me.  To get it to fail, 
> put some junk in /etc/ppp/options, i.e. a not currently existing modem 
> device such as /dev/usb/acm/0.

Couldn't resist:

laphish:~ # pppd
(null): This system lacks kernel support for PPP.  This could be because
the PPP kernel module could not be loaded, or because PPP was not
included in the kernel configuration.  If PPP was included as a
module, try `/sbin/modprobe -v ppp'.  If that fails, check t
laphish:~ #

Excellent output, isn't it?

Best regards,
Roberto Nibali, ratz

Re: ver_linux script updates

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 6904 bytes --]

> Not in sh, you need an ugly 'awk|sed' call to do the printf with 
> formatstrings. And for the declare, you just drop it. Anyway, it is 
> incomplete. Or you can decide to do it in bash, and leave the nice 
> printf functionality and other gadgets. 


declare removed, printf can be a sh-util file as well as a bash built in 
so I'm not concerned with that.

> Well it does, but since this stupid loadkeys writes everything to 
> stderr you need to parse the output again as follows (on my machine):
>
> loadkeys --junkoption 2>&1 | head -2 | tail -1 

What is the full output of your loadkeys program with --junkoption?  I 
avoided using combinations of programs and chose to concentrate on 
implementing a one program only solution which was common through the 
script.

loadkeys is part of the kbd/console-tools mess.  It can report a 
version, not report a version, use --version or -V depending on what 
package or date in history your package comes from.

> This is so gross you could as well do a strings on all those broken 
> binaries and maintain a table of offsets where to find the version 
> string. 

Unfortunately this would evolve into a big pile of versions and offsets 
that nobody would want to touch with a 10' pole.

> Well, I could help you (not a bash guru either) but the more I think 
> about this the more I think it's like the attempt of ESR to make an 
> autoconfigurator. Let's see if I get this correctly:
>
> o I read ../Documentation/Changes and read that
>   "This document is designed to provide a list of the minimum levels of
>    software necessary to run the 2.4 kernels, ..."
>   Why the hell do I need pppd to get a running 2.4.x kernel? I also do
>   not need reiserfs tools because I decided to run ext3. Well and on my
>   firewall I definitely don't need any pcmcia-cs package which isn't
>   even completely merged into the main kernel. 

One doesn't, it's a generic list that makes some assumptions.  To this 
end, I've decided to add some /proc checking before searching for 
certain tool versions.

> o I ask myself: What exactly does this file want to tell people. I
>   might be dumb but to run a kernel you need to be able to compile it,
>   link it an install it (noone asks for lilo).
> o OTOH, the original author mentions that this software list should be
>   checked before one even considers a bug to be a real bug an not just
>   some incompatibility with a wrong user space tool. 

One of the most visible points in history is pppd, for a long while it 
seemed like the most frequently recurring bug post was why pppd didn't 
work. The version the bug reporter had was less than required.

> o I ask myself: How define the set of tools then? Shouldn't we for
>   example include LVM or raid tools (as actually mentioned further
>   down in the same file)?

I've just added checking to a few of the version searches that takes 
note from /proc files as to whether or not said support is loaded and 
running.  In other words it doesn't make to much sense to check for pppd 
if the user doesn't use pppd.  Note that this can certainly be 
misconstrued and I should put a --verbose, or perhaps trying to be smart 
here will just make matters worse.

> o Why is this script still in the kernel tree? It is not mentioned
>   anywhere and it doesn't work reliably. 

It is mentioned in the top level REPORTING-BUGS file.

> The whole concept looks pretty broken to me, but then again I'm just a 
> little fart that doesn't see the big picture. 

It helps to clean up  some ambiguities when a bug report comes in.

>> Because it doesn't work as well as I want it to.  The previous 
>> writers of this script wrote it based on their choice of distribution 
>> and installed packages.  There has always been one or more strange 
>> outputs or breakage when I run it .  All of my software is compiled 
>> from original tarballs or cvs from the original author.  That means 
>> if the 
>
>
> I have such a distro too, I might run your version of the script on it 
> as soon as I got some sleep.

I've updated it a few times since you've last retrieved it.

> What if it hangs like in my example? I suggest you switch over to perl 
> or if you want I can give you my bash-exec-alarm-signal handler I once 
> wrote. But it's an extreme overkill to have such a thing built-in in 
> your script. 

Personally I dislike perl ['s bubblegum fixes everything approach], I 
don't think it's worth it to make such a heavy requirement of a user. 
 The hang has been removed by adding the --junkoption, and as far as I 
know none of the given version checks should hang now.

> Good luck. I agree that certain information is important to have, such 
> as:
>
> o  Gnu C                  2.95.3                  # gcc --version
> o  Gnu make               3.77                    # make --version
> o  binutils               2.9.1.0.25              # ld -v
> o  util-linux             2.10o                   # fdformat --version
> o  modutils               2.4.2                   # insmod -V 


Actually, on four of my seven systems I don't have 'fdformat' so 
'util-linux' would have failed, but I -do- have 'mount' which is part of 
the same package.

> I fail to see why I need more information from that script. But don't 
> let yourself stop by my comments. 

Agreed, some people use less, some people more.

> I don't know how many tools I've already patched exactly because of 
> this bloody annoyance. If one wants to build a stable, reliable, 
> reproducable and secure box, where information can be get with simple 
> scripts without thousands of lines of code for every little funny 
> thing a programmer out there thought might be better than all other 
> existing tools. 


The only problem with patching tools like this, is that it often doesn't 
get back to the author or doesn't get implemented by the author, much 
less it doesn't fix earlier versions of the same software.

>> In a side note, if anybody has a reliable way of getting pppd to 
>> -always- report the version number, please tell me.  To get it to 
>> fail, put some junk in /etc/ppp/options, i.e. a not currently 
>> existing modem device such as /dev/usb/acm/0.
>
>
> Couldn't resist:
>
> laphish:~ # pppd
> (null): This system lacks kernel support for PPP.  This could be because
> the PPP kernel module could not be loaded, or because PPP was not
> included in the kernel configuration.  If PPP was included as a
> module, try `/sbin/modprobe -v ppp'.  If that fails, check t
> laphish:~ #
>
> Excellent output, isn't it? 

Ugg, don't get me started.  "pppd --version"  means I want the version. 
 I don't give a flying fsck whether the kernel supports it or not, and I 
don't give a flying fsck if I have a messed up options file.  I want the 
version, nothing more, nothing less. What's worse, there isn't a textual 
string for the version in the binary that I can grab.

David


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3254 bytes --]

Re: ver_linux script updates

[Stefan Becker]

Hi!

David Ford wrote:
[...]
> Please provide feedback on it.

ECN detection doesn't work properly.

--- ver_linux.orig      Thu Feb 14 13:31:43 2002
+++ ver_linux   Thu Feb 14 13:31:33 2002
@@ -44,8 +44,8 @@
 }
 
 function truth {
-      if [ "$@" == "0" ]; then echo "disabled"; fi
-      echo "enabled"
+      if [ "$@" == "0" ]; then echo "disabled"; else
+      echo "enabled"; fi
 }
 
 pv "Gnu C compiler" "$(gcc --version 2>/dev/null)" gcc
@@ -153,5 +153,5 @@
 # kernel tuning options
 if [ -e /proc/sys/net/ipv4/tcp_ecn ]; then
        v=$(cat /proc/sys/net/ipv4/tcp_ecn)
-       pv "TCP option: ECN" "$(truth v)"
+       pv "TCP option: ECN" "$(truth $v)"
 fi

Greeting from Aachen,
Stefan Becker

Re: ver_linux script updates

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

Oh duh..that's what happens when you cut and paste only parts. :)

Thanks,
-d

Stefan Becker wrote:

>Hi!
>
>David Ford wrote:
>[...]
>
>>Please provide feedback on it.
>>
>
>ECN detection doesn't work properly.
>
>--- ver_linux.orig      Thu Feb 14 13:31:43 2002
>+++ ver_linux   Thu Feb 14 13:31:33 2002
>@@ -44,8 +44,8 @@
> }
> 
> function truth {
>-      if [ "$@" == "0" ]; then echo "disabled"; fi
>-      echo "enabled"
>+      if [ "$@" == "0" ]; then echo "disabled"; else
>+      echo "enabled"; fi
> }
> 
> pv "Gnu C compiler" "$(gcc --version 2>/dev/null)" gcc
>@@ -153,5 +153,5 @@
> # kernel tuning options
> if [ -e /proc/sys/net/ipv4/tcp_ecn ]; then
>        v=$(cat /proc/sys/net/ipv4/tcp_ecn)
>-       pv "TCP option: ECN" "$(truth v)"
>+       pv "TCP option: ECN" "$(truth $v)"
> fi
>
>Greeting from Aachen,
>Stefan Becker
>


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3254 bytes --]

Re: ver_linux script updates

[Roberto Nibali]

[-- Attachment #1: Type: text/plain, Size: 5434 bytes --]

Hi,

> declare removed, printf can be a sh-util file as well as a bash built in 
> so I'm not concerned with that.

Well, you added it again in version 1.4 of your script. I removed it. 
But I reckon you should write it in bash, can safe you some lines :)

> What is the full output of your loadkeys program with --junkoption?  I 
> avoided using combinations of programs and chose to concentrate on 
> implementing a one program only solution which was common through the 
> script.

Et voilà, feel free to vomit:

ratz@laphish:~ > grep declare ver_linux.*
ver_linux.txt:      declare -i count
ratz@laphish:~ > loadkeys --junkoption
loadkeys: unrecognized option `--junkoption'
loadkeys version 1.04

Usage: loadkeys [option...] [mapfile...]

valid options are:

	-c --clearcompose clear kernel compose table
	-d --default	  load "defkeymap.map"
	-h --help	  display this help text
	-m --mktable      output a "defkeymap.c" to stdout
	-s --clearstrings clear kernel string table
	-u --unicode      implicit conversion to Unicode
	-v --verbose      report the changes
ratz@laphish:~ >
> loadkeys is part of the kbd/console-tools mess.  It can report a 
> version, not report a version, use --version or -V depending on what 
> package or date in history your package comes from.

This is an information which you exactly don't have.

>> This is so gross you could as well do a strings on all those broken 
>> binaries and maintain a table of offsets where to find the version 
>> string. 
>  
> Unfortunately this would evolve into a big pile of versions and offsets 
> that nobody would want to touch with a 10' pole.

I was more making a joke on this one ...

> One doesn't, it's a generic list that makes some assumptions.  To this 
> end, I've decided to add some /proc checking before searching for 
> certain tool versions.

Ok, hope /proc-fs doesn't change semantics.

> One of the most visible points in history is pppd, for a long while it 
> seemed like the most frequently recurring bug post was why pppd didn't 
> work. The version the bug reporter had was less than required.

I haven't seen one in a year or so but I assume you know how Linux 
kernel development history goes, so it's you call. I saw that you made 
some /proc check for ppp. This is very acceptable then.

> I've just added checking to a few of the version searches that takes 
> note from /proc files as to whether or not said support is loaded and 
> running.  In other words it doesn't make to much sense to check for pppd 
> if the user doesn't use pppd.  Note that this can certainly be 
> misconstrued and I should put a --verbose, or perhaps trying to be smart 
> here will just make matters worse.

Yes, agreed.

>> o Why is this script still in the kernel tree? It is not mentioned
>>   anywhere and it doesn't work reliably. 
>  
> It is mentioned in the top level REPORTING-BUGS file.

Oups, my bad, sorry.

>> The whole concept looks pretty broken to me, but then again I'm just a 
>> little fart that doesn't see the big picture. 
> 
> 
> It helps to clean up  some ambiguities when a bug report comes in.

Ok.

> I've updated it a few times since you've last retrieved it.

I saw. I attached a diff of your 1.4 to 1.5. Changelog:

o bumped version
o made echo ' ' -> echo. No need to pass strings
o safe/restore IFS. This is important in case you want to output lkm
   with spaces instead of newlines
o function truth() should check $1==0 and not $@ because if one calls
   truth() with more arguments, it fails.
o added yesno() function for tained mode
o added space to isdnlegitimate to read isdn legitimate
o rewrote modules output: I think it is cleaner now.
o removed remaining declare, printf is still there
o fixed ECN test already reported by another guy
o added tainted lkm checking

> Personally I dislike perl ['s bubblegum fixes everything approach], I 
> don't think it's worth it to make such a heavy requirement of a user. 
> The hang has been removed by adding the --junkoption, and as far as I 
> know none of the given version checks should hang now.

You're right so far.

> Actually, on four of my seven systems I don't have 'fdformat' so 
> 'util-linux' would have failed, but I -do- have 'mount' which is part of 
> the same package.

Then use mount which is obviously more often deployed than fdformat.

> The only problem with patching tools like this, is that it often doesn't 
> get back to the author or doesn't get implemented by the author, much 
> less it doesn't fix earlier versions of the same software.

I've a some dozens of patches lying around exactly because one of your 
above mentioned reasons. This, however, will never change. You tool 
needs to be intelligent enough to handle broken user space apps.

> Ugg, don't get me started.  "pppd --version"  means I want the version. 
> I don't give a flying fsck whether the kernel supports it or not, and I 
> don't give a flying fsck if I have a messed up options file.  I want the 
> version, nothing more, nothing less. What's worse, there isn't a textual 
> string for the version in the binary that I can grab.

You seemed to have solved it in a way. One little invariant to fix 
remains though. Think what happens with your script, when one doesn't 
have proc-fs support ;)

Best regards,
Roberto Nibali, ratz

[-- Attachment #2: ver_linux-1.5.diff --]
[-- Type: text/plain, Size: 3231 bytes --]

--- ver_linux.txt	Fri Feb 15 02:33:08 2002
+++ ver_linux.new	Fri Feb 15 03:20:54 2002
@@ -6,7 +6,7 @@
 #
 PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH
 cat <<EOF
-Version: 1.4 (14 Feb 2002)
+Version: 1.5 (15 Feb 2002)
 If version fields appear unusual you may have an old version. Compare to the
 current minimal requirements in linux/Documentation/Changes. Please double
 check lines that say "error getting version, try manually" for validity.
@@ -19,9 +19,10 @@
 (grep ^Kernel /var/log/*dmesg* || (echo -n "Kernel command line: " ;\
       cat /proc/cmdline)) 2>/dev/null
 
-echo ' '
+echo
 
 function pv {
+      oldIFS=$IFS
       IFS=''
       title="$1"
       ver="$2"
@@ -30,27 +31,38 @@
       if [ "x$ver" == "x" -a "x$ev" != "x" ]; then
             eexists="$($ev --junkoption >/dev/null 2>&1 || echo $?)"
             if [ $eexists -eq 127 ]; then
+                  IFS=$oldIFS
                   return
             else
                   ver="error getting version, try manually"
             fi
       else
             if [ "x$ver" == "x" ]; then
+                  IFS=$oldIFS
                   return
             fi
       fi
 
       printf "%-34s%s\n" $title $ver
+      IFS=$oldIFS
 }
 
 function truth {
-      if [ "$@" == "0" ]; then
+      if [ "$1" == "0" ]; then
             echo "disabled";
       else
             echo "enabled"
       fi
 }
 
+function yesno {
+      if [ "$1" == "0" ]; then
+            echo "no";
+      else
+            echo "yes"
+      fi
+}
+
 pv "Gnu C compiler" "$(gcc --version 2>/dev/null)" gcc
 pv "Kgcc compiler" "$(kgcc --version 2>/dev/null)" kgcc
 
@@ -79,7 +91,7 @@
       awk '/^tune2fs/ {print $2}'|sed 's/,//')" tune2fs
 
 if [ $(grep -c reiserfs /proc/filesystems 2>/dev/null) -ne 0 ]; then
-pv "reiserfsprogs" \
+      pv "reiserfsprogs" \
       "$(reiserfsck 2>&1 |
       awk '/^reiserfsprogs/ {print $NF}')" reiserfsck
 fi
@@ -91,12 +103,12 @@
 fi
 
 if [ $(grep -c ppp /proc/devices 2>/dev/null) -ne 0 ]; then
-pv "pppd" \
+      pv "pppd" \
       "$(pppd --version 2>&1 |
       awk '/^pppd version/ {print $3}')" pppd
 fi
 
-echo "help me please, is this check for isdnlegitimate?"
+echo "help me please, is this check for isdn legitimate?"
 if [ $(grep -c isdn /proc/devices 2>/dev/null) -ne 0 ]; then
 pv "isdn4k-utils" \
       "$(isdnctrl 2>&1 |
@@ -144,17 +156,22 @@
       awk '/sh-utils/ {print $4}')"
 
 if [ -e /proc/modules ]; then
-      declare -i count
-      count=$(grep -c "^" /proc/modules)
-      if [ $count -gt 0 ]; then
-				modules="$(sed -e 's/ .*$//;s/\(.*\)/[\1]/' /proc/modules)"
-            pv "loaded modules" "$modules"
-      fi
+      while read a rest; do
+            modules="$modules [$a]"
+      done < /proc/modules
+      pv "loaded modules" "$(echo $modules)"
 fi
 
 echo
 # kernel tuning options
-if [ -e /proc/sys/net/ipv4/tcp_ecn ]; then
-	v=$(cat /proc/sys/net/ipv4/tcp_ecn)
-	pv "TCP option: ECN" "$(truth v)"
+TCP_ECN="/proc/sys/net/ipv4/tcp_ecn"
+if [ -e ${TCP_ECN} ]; then
+	v=$(< ${TCP_ECN})
+	pv "TCP option: ECN" "$(truth $v)"
+fi
+# kernel module taint information
+LKM_TAINT="/proc/sys/kernel/tainted"
+if [ -e ${LKM_TAINT} ]; then
+	v=$(< ${LKM_TAINT})
+	pv "modules tainted:" "$(yesno $v)"
 fi

Re: ver_linux script updates

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 3984 bytes --]

> Well, you added it again in version 1.4 of your script. I removed it. 
> But I reckon you should write it in bash, can safe you some lines :) 


This begs the question from the powers that be, what is the opinion of 
using sh vis bash?  'printf' is available as a bash builtin and as a 
sh-util file which should be found on most distributions; enough for me 
to say that lacking both bash and the sh-util printf should be a rare 
occurance.

>> What is the full output of your loadkeys program with --junkoption?  
>> I avoided using combinations of programs and chose to concentrate on 
>> implementing a one program only solution which was common through the 
>> script.
>
>
> Et voilà, feel free to vomit:
>
> ratz@laphish:~ > grep declare ver_linux.*
> ver_linux.txt:      declare -i count
> ratz@laphish:~ > loadkeys --junkoption
> loadkeys: unrecognized option `--junkoption'
> loadkeys version 1.04
>
> Usage: loadkeys [option...] [mapfile...]
>
> valid options are:
>
>     -c --clearcompose clear kernel compose table
>     -d --default      load "defkeymap.map"
>     -h --help      display this help text
>     -m --mktable      output a "defkeymap.c" to stdout
>     -s --clearstrings clear kernel string table
>     -u --unicode      implicit conversion to Unicode
>     -v --verbose      report the changes
> ratz@laphish:~ > 

Thanks.  This version of loadkeys comes from the kbd package (btw, 1.06 
was released a while ago).  The place where I'm using loadkeys is in the 
console-tools package, if you can find a tool that exists more commonly 
in console tools, great.  However I'm wondering if I really need to make 
the distinction in the script.  Is it really important to show the 
version of both kbd and console-tools? I'm beginning to think that 
avoiding this ugly mess would be nice, just print out a given version 
number from a series of a|b|c|d trials and whatever comes out first 
should be suitable.

>> loadkeys is part of the kbd/console-tools mess.  It can report a 
>> version, not report a version, use --version or -V depending on what 
>> package or date in history your package comes from.
>
>
> This is an information which you exactly don't have.

See above.

>>> This is so gross you could as well do a strings on all those broken 
>>> binaries and maintain a table of offsets where to find the version 
>>> string. 
>>
>>  
>> Unfortunately this would evolve into a big pile of versions and 
>> offsets that nobody would want to touch with a 10' pole.
>
>
> I was more making a joke on this one ... 

I kind of figured that :)

>> One doesn't, it's a generic list that makes some assumptions.  To 
>> this end, I've decided to add some /proc checking before searching 
>> for certain tool versions.
>
>
> Ok, hope /proc-fs doesn't change semantics. 

In this situation, it'll be a matter of keeping up with the Joneses. 
 There is an incredible amount of stubborness to changing already 
existing files in /proc so I'm not going to give this any thought.

>> One of the most visible points in history is pppd, for a long while 
>> it seemed like the most frequently recurring bug post was why pppd 
>> didn't work. The version the bug reporter had was less than required.
>
>
> I haven't seen one in a year or so but I assume you know how Linux 
> kernel development history goes, so it's you call. I saw that you made 
> some /proc check for ppp. This is very acceptable then. 

Not that I'm an old fart, but I discovered Linux back in the pre 1.0 
days. Linux was my roommate's get rich quick ISP idea when 56K dedicated 
lines were the bomb.

> You seemed to have solved it in a way. One little invariant to fix 
> remains though. Think what happens with your script, when one doesn't 
> have proc-fs support ;) 

Heh.. I could make work arounds, but that adds complexity which tends to 
add breakage.   Perhaps someone can suggest an ingenious method for 
figuring out what is/isn't supported by the kernel

Changes applied.

David


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3254 bytes --]