Calling sub scripts from control script in Unix shell

ohijames · 09-05-2017, 06:23 AM

I'm working on a control script that calls multiple other sub-scripts. However, when I try to run one of the sub-scripts with arguments the script doesn't see the arguments

. ./subscript.sh var1 var2

when I reference $1 from the sub script "echo $1" it comes up blank

Initially I thought $1 from the sub script was referencing $1 from the control script but then I realised $1 from the control script has a value.

I'm not sure if it has to do with the method in which I am calling the sub scripts with the double dots.

. ./subscript.sh var1 var2

Help and suggestions are all welcome.

O.

wpeckham · 09-05-2017, 06:54 AM

Just a little research should have resulted in several ideas that might serve. One is running the subscripts in a subshell using ( shell param1 param2 ) syntax. The power of the paren. If you need the value of the output then you can wrap it in an if statement or assign the output to a variable.

jlinkels · 09-05-2017, 07:41 AM

Original post deleted.

Sourcing instead of executing through shell is not the problem.

jlinkels

rtmistler · 09-05-2017, 07:42 AM

It would be a lot more helpful if you showed more of your code using [code][/code] brackets to enclose it.

Enable bash debugging with the statement:

Code:

set -xv

after your #!/bin/sh statement.

Answer the questions: What are var1 and var2 for us? Meaning, how did you populate them? Or are they an abstraction which you used to try to explain your script?

Turbocapitalist · 09-05-2017, 09:16 AM

You can also use functions in the shell script if you want to keep everything in one place and not call extra scripts.

Code:

#!/bin/sh           

set -x -e           

foo() {             
        echo "foo has '$1' as the first argument.";                             
}                   

date +"%F";

foo bar;            

date +"%T";

exit 0;

michaelk · 09-05-2017, 11:58 AM

In addition:

From the man bash page

Quote:

. filename [arguments]
source filename [arguments]
Read and execute commands from filename in the current shell
environment and return the exit status of the last command exe‐
cuted from filename. If filename does not contain a slash, file
names in PATH are used to find the directory containing file‐
name. The file searched for in PATH need not be executable.
When bash is not in posix mode, the current directory is
searched if no file is found in PATH. If the sourcepath option
to the shopt builtin command is turned off, the PATH is not
searched. If any arguments are supplied, they become the posi‐
tional parameters when filename 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 filename is not found or
cannot be read.

It is possible to call your script using source but as rtmistler pointed without context or seeing some of your code we do not know where it is going astray. As already stated do var1 and var2 exist and have values?

pan64 · 09-05-2017, 01:17 PM

or you just need to use:

Code:

subscript.sh "$var1" "$var2"

But I do not really understand your problem, would be nice to give a better example or sample code.
In your case $1 should contain the string var1 (not the content of var1, but the name of variable itself - if you used it without $).

rtmistler · 09-05-2017, 01:26 PM

I agree with the example by pan64, but will add my defensive coding comments:

I call a script or command with the full pathname, because I've been bitten before. While I realize this argument can go either way, regarding a proper $PATH environment setup to be uniform, my self-experience is with custom embedded Linux, so things are literally where I've placed them. If they are not, there is a problem.
Similarly I also ensure that if my script changes directories, that I save the $HOME from where I started. Or rather I save the `pwd` as a variable I typically name as HOME and then return there upon exit.
I also try to do single entry, single exit code, for scripts as well as programs. Sometimes difficult to achieve, but when I break that rule, I explain it in comments.

EDIT: I also agree with Turbocapitalist in that you might consider functions over calling another script.