Hi Tim, Alan.
>>> 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...
alias ls='ls --color=auto -FG'
...but it's only the -F option that appears to cause any
problems.
>> Perhaps we should use /bin/ls ?
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.
Personally, I'd strip out the PATH= line therein and use the one
in the environment precicely to deal with this point, as most
people will be using the same path for everything else as for
compiling.
> Not to mention that the change that Riley proposed didn't
> seem to work for me anyway.
> beastor:/home/tim# unalias -a
> beastor:/home/tim# cp /usr/src/linux/scripts/ver_linux .
> beastor:/home/tim# patch -p0 < rhw
> patching file `ver_linux'
> beastor:/home/tim# alias ls='ls -F'
> beastor:/home/tim# . ver_linux
> bash: /bin/bash: cannot execute binary file
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:
===8<=== CUT ===>8===
--- ver_linux~ Wed Dec 15 07:05:03 1999
+++ ver_linux Mon Mar 13 09:02:57 2000
@@ -1,10 +1,12 @@
#!/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
+(
+unalias -a
+echo
+echo 'NOTE: This script assumes that you use the same PATH when compiling'
+echo ' the kernel as is currently set in your environment. If such is'
+echo ' NOT the case, please set the relevant path, then rerun this'
+echo ' ver_linux script and report the resulting values instead.'
+echo
echo '-- Versions installed: (if some fields are empty or look'
echo '-- unusual then possibly you have very old versions)'
uname -a
@@ -30,3 +32,5 @@
expr --v 2>&1 | awk 'NR==1{print "Sh-utils ", $NF}'
X=`cat /proc/modules | sed -e "s/ .*$//"`
echo "Modules Loaded "$X
+echo
+)
===8<=== CUT ===>8===
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.
I wasn't on my development box when I wrote the first quoted
version, and was writing from memory, for which I sincerely
apologise...
> 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.
> 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.
> This is non-Earth-shattering stuff, but it's kind of handy.
Very true.
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:23 EST