0

Can you make a sh script call another script? (Apparently not.)

rwb@calleva:~/source$ ls -l
total 8
-rwxr--r-- 1 rwb rwb 50 Oct 22 03:38 caller.sh
-rwxr--r-- 1 rwb rwb 30 Oct 22 03:36 sourced.sh
rwb@calleva:~/source$ cat sourced.sh
#!/bin/sh

echo "sourced.sh"


rwb@calleva:~/source$ ./sourced.sh
sourced.sh
rwb@calleva:~/source$ cat caller.sh
#!/bin/sh


echo "caller.sh"


source ./sourced.sh


rwb@calleva:~/source$ ./caller.sh
caller.sh
./caller.sh: 5: source: Permission denied
rwb@calleva:~/source$
Tom Yan
  • 9,643
Richard Barraclough
  • 135

1 Answers1

2

source is an alternative name for the . builtin, but only in some shells. . is in POSIX, it's portable; source is not.

When writing code for sh, one should only use portable shell features. The basic point of writing code for sh is making it work in any implementation of sh. In general sh may be a symlink to bash, dash or some other shell. Even if this shell itself supports source, it may or may not support it when called as sh. And even if this shell itself supports source when called as sh, it's still a bad practice to write non-portable code when you are going to make sh interpret the code.

Maybe your /bin/sh does not support source; if so, it will treat source in source ./sourced.sh like any other not-a-keyword-and-not-a-builtin. Then maybe there is an executable file called source in some directory in your $PATH; if so, the shell will try to run it. Then maybe the mode of the file does not allow you to run it; if so, the error message will be source: Permission denied.

A solution is to use . instead of source. Any sh should understand . in the way you expected your sh to understand source.

Having source as an executable file is (in my opinion) uncommon. The above hypothesis, while plausible, may or may not be what happens in your particular case. Even if the solution does not (or does not fully) solve your particular case, using . instead of source in shell code for sh is still the Right Thing.

Kamil Maciorowski
  • 74,068