Re: ver_linux script updates

[David Ford <david+cert@blue-labs.org>]

[-- 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 --]