0

We have three main languages with which we perform system tasks: Bash, Ruby, and PHP, and Perl. Four, four main languages.

We use managed environment variables to provide authorization info that automated scripts need. For example, a mysql user account and password.

We'd like to use one single managed file to maintain these variables. In some instances, for example, in cron, these environment variables are not available. They are made available in CLI scripts because we source the env file in everyone's profile. But something like cron doesn't do that.

On the CLI, when the env file is sourced, any given script can access those variables. Bash has them directly, PHP in $_ENV, ruby in ENV, etc.

We can't source the file into non-Bash scripts, because most languages implement shell commands by running them in a subshell.

We considered parsing the Bash, converting to the script's lang, and running the equivalent of "exec(parsed_output)" on the resulting strings.

What is a good solution to providing managed environment vars to scripts running in cron, or similar?

JDS
  • 2,598
  • 4
  • 30
  • 49
  • Our solution is to use a wrapper shell script that sources the env vars in cases that need to use another language. – JDS Aug 02 '13 at 01:48

1 Answers1

0

We can't source the file into non-Bash scripts

No - but if they are already in the environment when the non-Bash runtime starts then it has access to the data - in php, via $_ENV, in perl via %ENV, in Ruby via ENV.

Since the startup script for most daemons (including apache, nginx, and the fastCGI daemons I've come across) is usually implemented as a shell script, then a default shell script can be sourced there.

symcbean
  • 21,009
  • 1
  • 31
  • 52