add support for environment variable references in map files

[pspencer@…]

I think that it would be useful to be able to use environment variables in a 
map file to specify directories etc in order to make map files more portable 
and to ease various testing situations.  My primary interest is in provided 
pre-packaged mapserver installations and pre-configured applications that can 
be easily installed on either a windows or linux platform.  On windows, it's 
not such a big deal because it is fairly easy to convince people to install 
stuff in a convenient location because they administer the machine, but on 
linux, the location of apps tends to be sensitive to the administrator's 
decisions.  Using environment variables for the web imagepath and shapepath 
would make mapfiles much more portable on these types of systems.

[sdlime]

Would it be enough to check for environment variables at map file load time? If
so then it's not too tough to add. What sort of a naming convention did you have
in mind?

[dmorissette]

> Would it be enough to check for environment variables at map file load time? 
> If so then it's not too tough to add. 

I've been struggling with that question too.  As you wrote it's MUCH simpler to
do the replacements in the mapfile parser, but the drawbacks are:
- If you use msSaveMap() then you lose the variable references, that's the main
drawback I see.  This will be especially bad for systems like MapLab/MapEdit.
- You cannot use variables from MapScript or via the CGI interface, but do you
need them anyway in those cases?

OTOH if we process the variables at runtime then that means adding overhead,
plus having to put those replacements all over the place, or document that they
apply only to file paths.  If we limit env. vars replacements only to file paths
then we could possibily plug the variable replacement code inside msBuildPath()
and that would do the trick since all paths in MapServer should go through this
function at some point.  That would also add the benefit that symbolsets and
fontsets could use env vars too for their paths.


> What sort of a naming convention did you have in mind?

I think we should go with $(VARIABLE) since that's what people are used to use
for referencing environment variables in shell scripts and in Apache config
files.  BTW, I have code that does this already in OWTChart, we just need to
copy it at the right place.  Feel free to reassign this to me if you would want
me to take care of this.

[dmorissette]

Hummm.. I was wrong, it doesn't seem that Apache uses $(VARIABLE) or uses
environment variables at all.  Duh!

And the function in OWT that does $(VARIABLE) replacements already is
OWTExpandEnvVars() in owt/htblock.cpp.  It currently works on an array of
strings and uses OGR's CPL functions but could easily be modified to operate on
a single string and have no CPL dependency.

[sdlime]

I like the idea of modifying the existing pathing code. I don't think we need 
wide spread env variable substitution. There's one exception though, the WEB 
IMAGEURL parameter. Seems to me that it would be very sensitive to installation 
location, but is never processed by msBuildPath.

Have you considered using the map_ syntax for CGI apps? I've used it to make 
installations more portable and it seems to work ok. Just have to edit one 
file, perhaps easier than setting env vars. Although losing the substitution 
strings is still an issue since most of the places you'd want to do it to are 
just strings.

[tomkralidis]

Any update on this one? Is this still desirable?

[sdlime]

Being this old it can't be much of a priority for anyone. Marking as FUTURE just so we don't loose it.