Bash config file for perl cgi script

Question

I would like to use a bash file as my config file for a project, so that the same config file can be used for all scripts regardless of language (especially bash and perl).

This is no problem from command line

$ source configfile.sh
$ ./perlscript.pl

But in a cgi script the answer's not so clear.

One way is using bash cgi file to execute a perl script.

#!/usr/bin/env bash
# mycgiscript.cgi
source /path/to/configfile.sh
perl /path/to/perlscript.pl
# i think the print functions in perlscript just output to the browser?

But if I do that, then bash is handling all of the http parameter parsing, and any of perl's cgi capabilities and modules become useless unless I am mistaken. Since perl would be doing all the leg work anyway, it seems using the cgi for parameter passing should be natural, but maybe there's no real problem with having bash manage the http request?

Another way is to use a Perl CGI file to parse the config file, and set the environment variables based on the parsing. The variables in configfile.sh reference each other though, causing complicated parsing and headaches.

So, what is the best practice for using a bash config file to set project-specific config/environment variables used by output generating Perl code, within a cgi script?

What is configfile.sh actually doing? Just setting environment variables? — Matt Jacob
Yes, just sets and exports environmnt variables, i updated question. The variables reference each other, though, so changing one variable changes mant others. — hilcharge
Why not use a properly formatted config file that the bash and perl script parses and sets their environment accordingly? — Ron Bergin
I'm inclined to agree with Ron. There's too much "magic" in your initial solution because of all the indirection, if you ask me. I'd pick a simple format that can be parsed universally and go that route instead. — Matt Jacob
By 'proper' or 'simple' format, do you mean just a bunch of VAR=HARDCODED_VALUE statements? Or would VAR=$VAL1/VALPART2 still qualify? — hilcharge

chicks chicks · Accepted Answer · 2015-09-15T19:22:55

Most of this is a bit hacky, but I like the idea of keeping your config centralized so let's see how it goes.

If you're writing a CGI script you need a web server. Let's assume apache for this answer.

There are several options:

reconfigure apache

So you could add your config script into the startup script for apache. This would set your environment variables before starting apache and those should be inherited by the child processes including your CGI script.

parse the config file

If you're not doing anything special with the shell in your config file it should be pretty trivial to parse it in Perl. Shell::Parser is a pre-existing module which seems to be pretty thorough about taking care of this.

process the config file

If you are doing fun shell tricks in your config file it might be easier to let the shell run it and then see what is left in the environment. Your CGI could run a script like:

source config.sh    # read config
env                 # print out environment

and then parse the output from the env in Perl.

real config library

If you're interested in a bigger rewrite, going for App::Config would be my recommendation. It would not let you keep your config in shell files, but you could write a Perl script that would generate your shell configs from the App::Config configs.