lkml.org 
[lkml]   [2002]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ver_linux script updates
> 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

[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.536 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site