On Mon, Mar 13, 2000 at 09:07:43AM +0000, Riley Williams wrote:> 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...

It's somewhat fair, but a bit exaggerated.

> [...] > 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.

> 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 thingthat the regular ver_linux script does.

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.

> 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.

> > 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 informationthat uname -a provides. The only things missing are themachine type and processor type.

> > 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? The only instance I can think of would be whenls is not in /bin. Please provide an example.