CODEWITHSUNDEEP
shellunix
user5705451
user5705451

Reputation: 35

Passing parameter from one script to another- Shell Scripting

I have a main_script.sh which will call sub_script.

I have a variable in sub_script which i would like to access in main script

I tried "export" and "env" with the variable but when i'm trying to echo it in main_script i'm not getting values.

for example:

sub_script.sh

export a=hello
echo $a

main_script.sh

$PGMHOME/sub_script.sh > output_file
echo $a

FYI : sub_script.sh is executing properly because I'm getting value of 'a' in output_file But when I'm echoing the value of a in main_script, I'm not getting it.

p.s : I know I can assign the variable directly in main_sript.sh but this is just an example and i have big processing done in sub_script.sh

Upvotes: 0

Views: 164

Answers (2)

kometen
kometen

Reputation: 7772

Parameters to script are passed like $1, $2 etc. You can call main_script.sh from sub_script.sh and call main_script.sh again.

main_script.sh

#!/bin/sh
echo "main_script"
./sub_script.sh "hello world!"

sub_script.sh

#!/bin/sh
if [ "${1}" = "" ]; then
    echo "calling main_script"
    ./main_script.sh
else
    echo "sub_script called with parameter ${1}"
fi

./main_script.sh

calling main_script
main_script
sub_script called with parameter hello world!

Upvotes: 0

torek
torek

Reputation: 487755

Environments (export-ed variables) are passed only "downwards" (from parent to child process), not upwards.

This means that if you want to run the sub-script from the main-script as a process, the sub-script must write the names-and-values somewhere so that the parent process (the main script) can read and process them.

There are many ways to do this, including simply printing them to standard output and having the parent script eval the result:

eval $(./sub_script)

There are numerous pitfalls to this (including, of course, that the sub-script could print rm -rf $HOME and the main script would execute that—of course the sub-script can simply do that directly, but it's even easier to accidentally print something bad than to accidentally do something bad, so this serves as an illustration). Note that the sub-script must carefully quote things:

#! /bin/sh
# sub-script
echo a=value for a

When evaled, this fails because value for a gets split on word boundaries and evals to running for a with a=value set. The sub-script must use something more like:

echo a=\'value for a\'

so that the main script's eval $(./sub_script) sees a quoted assignment.

If the sub-script needs to send output to standard output, it will need to write its variable settings elsewhere (perhaps to a temporary file, perhaps to a file descriptor set up in the main script). Note that if the output is sent to a file—this includes stdout, really—the main script can read the file carefully (rather than using a simple eval).

Another alternative (usable only in some, not all, cases) is to source the sub-script from the main script. This allows the sub-script to access everything from the main script directly. This is usually the simplest method, and therefore often the best. To source a sub-script you can use the . command:

#! /bin/sh
# main script
# code here
. ./sub_script  # run commands from sub_script
# more code here

Upvotes: 1

Related Questions