lkml.org 
[lkml]   [2000]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.104 / U:1.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site