any explanation for thsi shell script behaviour

hello

whats the difference between excuting a shell script as

a)sh myscript.sh
b). ./myscript.sh

i noticed that my shell script works fine when i run it as . ./myscript
.sh but fails when i run it as sh myscript.sh could anybody explain why.

the shell script is very simple

#!/bin/sh
startx

regards
Hrishy

Try using the full path to the startx script... the . ./script will work because your path is set up, but ./script or sh script may not if it's not in the default path...

Hmm Livin free

Both of the scripts

a)sh myscript.sh
b). ./myscript.sh

are in my path .but i dont undersatnd the difference in behaviour

regards
Hrishy

In one case a subshell runs the script, in the second case the login shell runs the script.

I'm not sure. I think that in the both cases is spawned child shell.

I would have to disagree with that statement that both cases spawn a child shell.

Perderabo is correct.

Agreed. Perderabo is correct.

...from the bash man page regarding dot "." notation or
"source"ing...

. filename [arguments]
source filename [arguments]
Read and execute commands from filename in the cur-
rent shell environment and return the exit status
of the last command executed from filename. If
filename does not contain a slash, pathnames in
PATH are used to find the directory containing
filename. The file searched for in PATH need not
be executable. The current directory is searched
if no file is found in PATH. If any arguments are
supplied, they become the positional parameters
when file is executed. Otherwise the positional
parameters are unchanged. The return status is the
status of the last command exited within the script
(0 if no commands are executed), and false if file-
name is not found.

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" ... :-((