Messages in this thread Patch in this message | | | Date | Mon, 13 Mar 2000 20:45:42 +0000 (GMT) | From | Riley Williams <> | Subject | Re: ver_linux script |
| |
Hi Tim.
>>>>> alias ls='ls -F' >>>>> . ver_linux
>>>> alias make='echo banana' >>>> make bzImage
>>>> That doesnt work either ..
>> Is that really a fair comparison? I know quite a few people >> who use the alias I quoted, along with several others. Quite >> a common alias for the above command on Linux systems is...
> It's somewhat fair, but a bit exaggerated.
I have to say that I don't consider it anything like a fair comparison. Sorry.
>> My reading of that file is that it tries to use whichever >> version of each command is nearest in the path, and unless >> I'm wrong, the `make` command does not respect aliases, but >> does respect the PATH variable, and it was for this reason >> that none of the commands therein use paths. I tried to >> keep that behaviour.
> I don't know about this, but if it's true then you're right, > using /bin/ls might be the Wrong Thing[tm] to do.
That's what the comment at the top of the original version indicates as being the reason for the path specified therein, and notes that if a different path is used on that systemn, then the path in question should be echoed there.
>> I've checked now, and indeed it can't work as written, but >> the following alternative diff does exactly what was >> intended and has been verified through long years of use. >> This is the variant I was actually using:
> [patch snipped]
> This doesn't work for me either. It seemed to do the same > thing that the regular ver_linux script does.
I've just checked, and it doesn't work for me either now, yet it's the one I developed when RedHat 5.2 was current, and it clearly worked then. Yours truly is clearly puzzled as to what is going on there !!!
I have now developed one that actually works, but it does so by changing the mode of the ver_linux script to 755 rather than the 644 that it comes with, then just running it. I know my original version avoided that and worked, but I've no idea why the one I have stored as being the version in question doesn't...
> I'm not sure if I'm getting the same problem you are. > Normally I get
> Linux C Library 2.1.3
> but with ls aliased to 'ls -F', I get
> Linux C Library 1.3.so*
> even with the patch you suggested.
In my case, the existing script gives "1.2.so*" whereas the revised script gives "2.1.2", both with the alias present.
>> The key to it doing what is required are the brackets, >> which cause the enclosed to be run in a separate subshell >> and thus insulate it from the calling environment.
> Interesting.
At least, that's part of the key, but clealry there's something else as well, and I'm not sure what...
>>> Seriously though, Alan, I think it's useful to see what >>> version the kernel has been compiled with, so I've written >>> up a patch against 2.3.51 which uses /proc/version instead >>> of "uname -a" (provided that you have /proc/version, of >>> course).
>> Probably a better idea would be to provide both.
> Well, /proc/version provides most of the same information > that uname -a provides. The only things missing are the > machine type and processor type.
I must have been asleep when I made that comment, sorry... Please ignore it.
>>> I've included the change to use "/bin/ls" instead of >>> just ls, which seems to fix the weird behaviour that >>> Riley describes.
>> It could also prevent the script from producing the >> correct answers in some cases, so I would suggest >> basing a replacement on the application of the above >> diff to the original version.
> It would?
It COULD - not WOULD - although in that case, I wouldn't expect it to. That's the direct implication of the comment at the start of the current version.
However, doing that only fixes the problem with an alias for ls whereas the version I was suggesting [used to] fix the problem with aliases to ANY command.
I've never used an alias for any other command in that script, but then, the developers have obviously never used an environment where an alias for the ls command existed that included -F was present, and that didn't stop the script getting hurt...
> The only instance I can think of would be when ls is > not in /bin. Please provide an example.
I can't think of an example that definately would, other than what you suggest.
Anyway, here's a patch that works on a generic basis, and includes your patch to use /proc/version if available. Whether this will be acceptable is another question...
===8<=== CUT ===>8===
--- ver_linux~ Wed Dec 15 07:05:03 1999 +++ ver_linux Mon Mar 13 20:40:05 2000 @@ -1,13 +1,29 @@ #!/bin/sh -# Before running this script please ensure that your PATH is -# typical as you use for compilation/istallation. I use -# /bin /sbin /usr/bin /usr/sbin /usr/local/bin, but it may -# differ on your system. -# -PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH -echo '-- Versions installed: (if some fields are empty or look' -echo '-- unusual then possibly you have very old versions)' -uname -a +if [ "`basename $0`" != "ver_linux" ]; then + if [ ! -x ver_linux ]; then + chmod 755 ver_linux + fi + ./ver_linux +else +unalias -a +cat <<.EOF + +NOTE: This script expects to be run with the same PATH that you use when + compiling the kernel or application you are having problems with. + If such is not the case, please disregard the following, set your + PATH to the one you use, and rerun this script. + +The following versions appear to be installed: (if some fields are empty +or look unusual, then it is possible that you have very old versions +thereof) + +.EOF +if [ -f /proc/version ]; then + cat /proc/version +else + uname -a +fi +echo insmod -V 2>&1 | awk 'NR==1 {print "Kernel modules ",$NF}' echo "Gnu C " `gcc --version` ld -v 2>&1 | awk -F\) '{print $1}' | awk \ @@ -30,3 +46,5 @@ expr --v 2>&1 | awk 'NR==1{print "Sh-utils ", $NF}' X=`cat /proc/modules | sed -e "s/ .*$//"` echo "Modules Loaded "$X +echo +fi ===8<=== CUT ===>8===
Ideally, there would be some means for the `patch` command to specify that a particular file had changed mode and was now executable (or wasn't, as the case may be), but I can't see that coming any time soon...
Best wishes from Riley.
* Copyright (C) 2000, Memory Alpha Systems. * All rights and wrongs reserved.
+----------------------------------------------------------------------+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this XXXX feature, but I bet someone | | else has already done so and is just about to release their patch. | +----------------------------------------------------------------------+ * http://www.memalpha.cx/Linux/Kernel/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |