0

I am working on automating some existing processes through linux shell scripts. What I want to do is run a script remotely through SSH that will then complete a number of tasks on the remote host.

The current file structure is like this:
setup.sh -> exports a list of environment variables
automate.sh -> executes setup.sh then runs automation

Let's say setup.sh does "export VAR=/test" and at the end of the automate.sh script I put the following line "env | grep VAR".

After unsetting VAR and then executing automate.sh, the variable does not get output, meaning it is empty.

Setting the environment variables in .profile or .bashrc will not work for me as setup.sh dynamically sets environment variables based on my parameters (For example, executing code from different regions requires different variables to be set, but all variables have the same name so the same code can be used for all regions).

I am assuming the problem here comes from automation.sh creating a new shell, then setup.sh creating a new child shell, meaning that the exported variables are not available in automation.sh

Can anyone with more experience tell me if this is likely the case? Or how I would verify if this is the case or not? Any suggested solutions would be welcome too.

Thanks.

Update: A suggested solution was to source setup.sh instead of executing it. This solves the problem. However, it would then mean I would need to source setup.sh in multiple places as other scripts will be executed later after automation.sh has complete.

Is there any way to run setup.sh and have the exported variables available to all following scripts?

Craig
  • 1
  • 1
  • What do you mean with "_calls setup.sh then runs automation_"? Does it execute `setup.sh` or does it source it? And when testing this locally, did you `unset VAR` before executing `automate.sh` (just to be sure it was not already set beforehand)? – Renaud Pacalet Jun 08 '22 at 11:22
  • First: "calls setup.sh then runs automation" - By this I mean executes setup.sh. "sh setup.sh" Second: That's a good point. I hadn't thought to do that, so no I wasn't unsetting it before hand. I just tried to do that, and it does not work locally either in this structure – Craig Jun 08 '22 at 11:29
  • OK, please edit your question to add this important information (`call` is not clear). Next, instead of executing `setup.sh` try to source it: `source setup.sh` or `. setup.sh` (dot + space + `setup.sh`). The former sets the environment variables in a child shell only. The latter sets them in the context of the current shell. – Renaud Pacalet Jun 08 '22 at 11:32
  • Sourcing the script solves this case. However, there can also be other scripts called after automation.sh completes which also require those environment variables. Is there a way to call "sh setup.sh" early enough that all following scripts will have access to the exported variables? – Craig Jun 08 '22 at 11:45
  • Simply make these definitions available to the parent shell: remove the sourcing of `setup.sh` from your other shells and use `ssh remote '. setup.sh; ./automation.sh; ./someother.sh...'` – Renaud Pacalet Jun 08 '22 at 11:48

0 Answers0