Shell Programming and Scripting

I agree with rwb1959.

If you do this:

. ./myscript

It will source the script, not execute it. However, the following should be equivalent:

sh myscript
./myscript <- only one .

Back to the original question, type this from command line:

which sh

This will give you the path to sh. If it doesn't return, there is your problem. Next run:

echo $PATH

Do you see the path returned by "which" listed. If you don't, you will either have to add it to your PATH or run:

/(path from which)/sh myscript

I think this would be pretty unlikely but you might want to check anyway. Both ./myscript and sh myscript should work fine.

Actually, these do work differently and how apparent the differences are depends on your kernel. When the trick of allowing the kernel itself to run a script first appeared, the suid and sgid bits were respected. With a kernel like that, "./myscript" could run with the effective uid or effective gid set according to the file's permissions. On the other hand, "sh ./myscript" will never run with alternate permissions.

This opened up a nasty security hole that could not be closed and most kernels these days no longer support suid/sgid shell scripts.

However the development of the fd psuedo-filesystem has provided a way to close that formerly unclosable hole. So it's possible that suid/sgid scripts may return. And in any event, I wouldn't bet the rent that no kernel currently running supports suid/sgid scripts.

Excuse me. I didn't read correctly.

I read " . ./script" just as " ./script" ... :-((