> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:01:06 EST