Re: Switching Between Development and Production Environments
by dragonchild (Archbishop) on Oct 06, 2003 at 16:28 UTC
|
Why not pass the name of the datafile in? Sounds like the easiest way to do it ... Another would be to have an ini file in the same directory as the perl script and have it know where the appropriate datafile should be.
Both those ways are examples of separating data from function. Don't hardcode stuff if you don't have to.
------ We are the carpenters and bricklayers of the Information Age. The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6 Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] |
|
Thanks dragonchild. I should have mentioned that the script is being run as a web app, so I can't really pass in the data file as an argument without exposing it to users. (As far as I know.) I like the ini file idea. I'll give that a shot. Thank you.
| [reply] |
Re: Switching Between Development and Production Environments
by Melly (Chaplain) on Oct 06, 2003 at 16:29 UTC
|
I doubt my skills are any better than yours, but for what it's worth I develop in an identical environment, so...
- You could check for the O/S ($^O)
- You could have a separate option file
BTW I tend to use a small perl-script to change the shebangs back-and-forth
Tom Melly, tom@tomandlu.co.uk
| [reply] |
Re: Switching Between Development and Production Environments
by seaver (Pilgrim) on Oct 06, 2003 at 16:40 UTC
|
svsingh and melly,
kinda off topic, but seeing linux is free and grub is stable, why put yourself through such pain when the production environment is linux, and add linux to your machines as a development environment??
Sam | [reply] |
|
Switching to a the same OS doesn't solve this particular
problem. Of course there are advantages if your development,
testing and production areas all use the same platform, but
that has little to do with configuration issues. Typical
configuration issues include (but are not limited to):
user names, passwords, database names, database servers,
file and directory names, hostnames, and port numbers.
One way of dealing with it is by using environment variables,
but that quickly becomes unwieldy. A typical way of dealing
with this is configuration files. Configuration files could
be stored at a fixed location (say /etc/opt/app/application-name/config); a location relative
the program, the working directory during startup, or the
home-directory of the user; given as a parameter of the
program; passed via an environment variable; or some combination of them.
Abigail
| [reply] |
|
| [reply] |
|
Well, I wouldn't replace my win machine, but I don't really have any excuse for not setting up a linux box to act as a development environment/firewall/etc.
That aside, I doubt that I'd want to implement the kind of path-structures one typically comes across on an ISP's CGI-server
(OT) IMHO the world would be a happy shiny place if all desktops were windows, and all servers were linux, BWTFDIK?
Tom Melly, tom@tomandlu.co.uk
| [reply] |
Re: Switching Between Development and Production Environments
by freddo411 (Chaplain) on Oct 06, 2003 at 17:29 UTC
|
On my project I maintain a small "config" file that contains all variables that have unique values based on the hostname that the script is running on. Examples are: the path to ORACLE_HOME, etc. etc.
To keep things organized, don't put anything else in this file.
Care must be taken when switching from dev to production to use the "correct" config file. One trick to help with this is to name the config files like "<hostname>.config" and have the parent code read in $hostname.config
I have a very simple parsing routine that reads each line in the config file, ignores comments lines, and sets a name value pair in a hash. I also set some needed ENV vars too.
In my code I use the values like so:
my $localvar = $CONFIG{'TEMP_DIR'};
-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday
| [reply] [d/l] |
|
Why not make a switch in the config file like:
if(`hostname` eq 'athena'){ # or ($^O =~ /win/i)
$tempdir = '/usr/tmp';
}else{
$tempdir = '/tmp';
}
| [reply] [d/l] |
Re: Switching Between Development and Production Environments
by cbraga (Pilgrim) on Oct 06, 2003 at 16:39 UTC
|
You can try using Cygwin, which emulates a Unix enviroment under Windows. | [reply] |
Re: Switching Between Development and Production Environments
by traveler (Parson) on Oct 06, 2003 at 22:51 UTC
|
Since you commented above that this was a "web app", you can use the SERVER_SOFTWARE CGI environment variable to discover the server type and/or OS (the latter if you are running, say, Apache on both platforms). You can use that information to decide where to look for a config file, or the datafile itself, presumably.
HTH, --traveler | [reply] [d/l] |
Re: Switching Between Development and Production Environments
by Roger (Parson) on Oct 07, 2003 at 01:23 UTC
|
There is another quick way to find out whether the perl script is running under Unix or Windows by checking for the existance of a system file, say, /bin/ls. The following code would work well:
$hosttype = (-x "/bin/ls") ? "UNIX" : "WINDOWS";
print "$hosttype\n";
| [reply] [d/l] |
Re: Switching Between Development and Production Environments
by svsingh (Priest) on Oct 07, 2003 at 04:03 UTC
|
| [reply] |