>
> I wrote
>
> I found no way to get the download script to run the bash script: I
> had to manually 'source' it instead. I never worked out why.
> (Perhaps a security feature in bash?)
>
> It turns out the 'Perhaps' guess was correct. Bash scripts are prevented
> from simply running bash scripts in the current directory: various users
> have raised questions about this posted online and various workarounds
> exist. But changing the invoked script to use tcsh works and is simpler
> than any of the solutions I found online. Perhaps there is some reason why
> that should not be done.
What you wrote looks very strange. AFACS any such restriction would
violate Posix standards and 'bash' claims standard compliance.
Anyway, on my system creating two files 'foo.sh' and 'bar.sh' in
'/tmp' and executing 'foo.sh' when '/tmp' is current directory
works OK. Apparently some systems make '/tmp' unexecutable,
so you may be forced to replace '/tmp' by something which can
contain executables. Anyway the following is supposed to
work portably, as long as 'bash' is in '/bin' directory
(if that is a problem there is workaround using 'env' program).
---------------<foo.sh cut here>----------------------
#!/bin/bash
./bar.sh
---------------<cut here>--------------------------
---------------<bar.sh cut here>----------------------
#!/bin/bash
echo "OK"
---------------cut here>--------------------------
Both files should be marked as executable. Note that
'#!' line is necessary to make it into proper executable.
The '#!' line is handled by kernel, so it should not matter
what called the script, caller simply uses 'exec' system call
and all business with calling interpreter (that is the shell)
is done by kernel.
And './bar.sh' is full relative pathname, without relying
on PATH (which normally does not contain current directory).
--
Waldek Hebisch
