Coherence between inline and external script calling

From the documentation:

The job script is separated into two parts. User scripts and environment (env-script, [environment], pre-script, script and post-script) are isolated and executed in a separate subshell process. Any changes to environment, traps, etc., done in any of them are visible in subsequent parts, but will not interfere with the parent shell process.

Now consider the following trivial workflow:

[scheduling]
    [[graph]]
        R1 = "setup"

[runtime]
    [[setup]]
        pre-script="a=1"
        script="echo $a"

as expected, this works fine.
However if we now create bin/script.sh containing “a=1” then

[scheduling]
    [[graph]]
        R1 = "setup"

[runtime]
    [[setup]]
        pre-script=script.sh
        script="echo $a"

then the job errors, as $a isn’t defined.
This can, of course, be fixed by changing pre-script=script.sh to pre-script=". script.sh"


This behavior is, as far as I’m aware, not documented (not even here). It doesn’t feel intuitive, not feel in line with the documentation quoted above.

Is this the expected behavior ?

(Using Cylc 8.2.4 with python3.9 on ubuntu 22)

Hi @abarral

Technically that’s not a Cylc thing, it’s just down to the normal rules of shell variable scoping (well, and also the fact that Cylc simply writes script config items verbatim to the job file so it works just like any other script).

This:

# flow.cylc
[runtime]
   [[setup]]
        pre-script = "a=1"
        script = "script.sh"  # contains "echo $a"

results in:

# job.sh
a=1
script.sh  # runs in a subshell, so `a` is undefined unless you export it!

And, sourcing the script (e.g. . ./script.sh) works because that runs each line in the same shell as a=1, not a subshell.

Long story short, you just need:

pre-script = "export a=1"
1 Like

Cylc simply writes script config items verbatim to the job file

Thanks, that makes a lot of sense. That being said, I think it would be better if it were explicit in the documentation :slight_smile:

Yes, I think we should document exactly how the script items relate to job file content.