Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Switching Between Development and Production Environments

by svsingh (Priest)
on Oct 06, 2003 at 16:21 UTC ( [id://296981]=perlquestion: print w/replies, xml ) Need Help??

svsingh has asked for the wisdom of the Perl Monks concerning the following question:

I normally do my development at home (Windows) and then upload my code and let it run on the server (Linux). It's a bit of a headache, but it works for me. To make this easier, all of my programs start with the following lines:
#!c:\perl\perl.exe #!/usr/local/bin/perl use strict;

When I upload the file to the server, I delete the first line and things seem to work. However, I'm now writing a script that has a data file. It seems that I need to refer to this file by an absolute path and I'm trying to implement this without requiring a lot of editing on the server-side version.

My current solution has me setting the path to the datafile as a global variable. The script checks the path to Perl and sets the value of the variable accordingly. Here's the code:

use strict; use Config; my $datafile = ""; if ( $Config{"perlpath"} =~ m/^c:/i ) { $datafile = 'c:\work\perl\data'; } else { $datafile = '/usr/svsingh/data'; }

That seems to work, but it looks like a kludge to me. Here are my questions:

  1. Other than putting the data file in the same directory as the script, is there a way around this issue? The directory structure for my ISP is quite funky, so I'd rather not use a relative path.
  2. Is there a better way than testing $Config{"perlpath"} to figure out which computer the script is running on and, therefore, where the data file is?

Thanks for your help.

Replies are listed 'Best First'.
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.

      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.
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
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

      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

      They like windows?

      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
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

      Why not make a switch in the config file like:
      if(`hostname` eq 'athena'){ # or ($^O =~ /win/i) $tempdir = '/usr/tmp'; }else{ $tempdir = '/tmp'; }
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.
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

Re: Switching Between Development and Production Environments
by svsingh (Priest) on Oct 07, 2003 at 04:03 UTC
    Just a quick update. I tried the separate config file technique suggested by dragonchild, Melly, Abigail-II, and freddo411. It worked perfectly and keeps the code a bit simpler.

    Thanks everyone for your help and ideas. I appreciate it.

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";

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://296981]
Approved by adrianh
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2024-03-28 22:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found