Messages in this thread | | | Date | Fri, 15 Feb 2002 02:46:43 -0500 | From | David Ford <> | Subject | Re: 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] | |