When you run something, from a bash, it inherits the exported variables, plus the ones given in the same command line.

Suppose this case:

xavi@bromo:~$ export -p
declare -x HOME="/home/xavi"
declare -x TERM="linux"
declare -x USER="xavi"
xavi@bromo:~$

Say you echo something not defined: You don’t get anything, as expected:

xavi@bromo:~$ echo $ABC $XYZ

xavi@bromo:~$

You can place this echo inside a bash script, for example:

xavi@bromo:~$ cat /tmp/test.sh
#!/usr/bin/env bash
echo $ABC $XYZ

Then give it execution permissions:

xavi@bromo:~$ chmod a+x /tmp/test.sh
xavi@bromo:~$

Now, if you execute the script it also says nothing, but if you prefix them with variable assignment the value lives “exclussively” inside that call. See examples with hello-bye and orange-banana. If you later just show the values, they are not there:

xavi@bromo:~$ /tmp/test.sh

xavi@bromo:~$ ABC=hello XYZ=bye /tmp/test.sh
hello bye
xavi@bromo:~$ ABC=orange XYZ=banana /tmp/test.sh
orange banana
xavi@bromo:~$ echo $ABC $XYZ

xavi@bromo:~$

This would be a good approach for the solution of Fabien Papet: To prefix the cron call with the variable assignment.

But if you cannot do that, you can go furthter:

Env vars are not inherited when not exported but inherited when exported: See this:

xavi@bromo:~$ ABC=pita
xavi@bromo:~$ XYZ=pota
xavi@bromo:~$ /tmp/test.sh

xavi@bromo:~$ export ABC=pita
xavi@bromo:~$ export XYZ=pota
xavi@bromo:~$ /tmp/test.sh
pita pota

You could take advantage of bash dot-import command . to import variables.

Place in these files those contents:

xavi@bromo:~$ cat /tmp/fruits
export ABC=orange
export XYZ=tangerine
xavi@bromo:~$ cat /tmp/places
export ABC=Paris
export XYZ=Barcelona
xavi@bromo:~$

Note that the previous files do not have a she-bang as they are not meant to be executed, they do not have to create a bash instance. They are meant for inclussion from an existing bash instance.

Now edit the test.sh to make an inclusion of a file which we’ll pass via the first command line parameter:

xavi@bromo:~$ cat /tmp/test.sh
#!/usr/bin/env bash

. $1

echo $ABC $XYZ
xavi@bromo:~$

You can now play with the invocation. I still have the pita-pota pair from the last test. See what happens:

xavi@bromo:~$ echo $ABC $XYZ
pita pota
xavi@bromo:~$ /tmp/test.sh /tmp/fruits
orange tangerine
xavi@bromo:~$ /tmp/test.sh /tmp/places
Paris Barcelona
xavi@bromo:~$ echo $ABC $XYZ
pita pota
xavi@bromo:~$

The first line echo $ABC $XYZ displays our current environment.

The second line invokes a new bash (via the she-bang of /tmp/test.sh) and as pita-pota were exported they are momentarily there. But as soon as . $1 is executed, it is expanded into . /tmp/fruits which overrides the environment by exporting new variables, thus the result.

The second scripts (the one with fruits) ends, so the bash is terminated and its environment is destroyed. We return to our main bash. In here we still have pota-pita. If we had printed now, we’d see the pita-pota. We go with the places, now.

The reasoning with the places is identical to the reasoning with the fruits.

As soon as we return to the main bash, the child env is destroyed, so the places have been blown away and we return to the first initial environment with pita-pota, which is then printed.

So…

With all this you can:

1. Setup a bash script that wraps:
   1. loading the environment from some
      place.
   2. Call the php bin/console
2. In the cron, do not invoke the php but your wrapper script.

This allows you to

1. Change the script with different environments without depending on versioning.
2. Keep your credentials and configuration separated from the code.

In conclusion:

• Make your source version control system to have the cron versioned, and the wrapper bash script versioned.
• Make your deployer to place a different “includable” parameters file in each environment.
• Make your cron to call the wrapper.
• Make your wrapper to setup the env vars and call the php bin/console.

Does this solve your issue?