Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Our solution is to use a wrapper shell script that sources the env vars in cases that need to use another language. –  JDS Aug 2 '13 at 1:48

1 Answer 1

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.