1) Instead of changing the #! line, you could have OS-specific .pl's which initialize variables to OS-specific values, the uses do to execute the common code.

2) You shouldn't need to use $sep. For that, we have core modules File::Spec and File::Basename.

applic_linux.pl
---------------
#!/usr/bin/perl

our $logdir = "/home/ghodmode/logs";

do 'applic.pl';


applic_win32.pl
---------------
#!c:\perl\bin\perl

our $logdir = "c:\\xampp\\xampp\\webapp\\logs";

do 'applic.pl';


applic.pl
---------
use strict;
use warnings;

BEGIN {
   our $logdir;
   die(...) unless defined $logdir;
}

use File::Spec ();

my $logfile = File::Spec->catfile($logdir, 'error_log.txt');

...
[download]

Better yet would be to use a config file to hold the name of the log dir. That would be both OS-independant and more useful.

And if you're willing to install a module from CPAN or package it along with your app (PAR), consider using Path::Class instead of File::Spec, as it has a considerably nicer interface. (It's pure love.)

It uses File::Spec under the hood, of course.

You can make Apache on Windows find the correct perl binary through the registry instead of the shebang line. That way you can leave it intact for use on Linux. (You can use the Apache directive ScriptInterpreterSource Registry).

Perl works fine on Windows using a forward slash as path separator, so you could drop that variable. For really spiffy cross-platform paths, I suggest File::Spec (look at the catfile function).

Thanks to everyone...

I didn't know about File::Spec and I will definitely be using that.

Currently, my application consists of 16 Perl files and it's still growing. So, having a version of each of those, for each platform, isn't a good choice for me because they are still undergoing changes. I might need to make a change in the code, then have to remember to do it exactly the same way two more times.

I'm already using a separate configuration file. That does save some time when I need to copy the code to the other platforms.

The ScriptInterpreterSource directive is new to me also. It might save me the monotonous task of editing every file every time I move the code to the Windows box, but I am curious what I need to do to make it work. I've read the documentation . This may be a Windows question rather than a Perl question, but maybe you can still help me out: The doc says it will use Shell\ExecCGI\Command or, if it does not exist, Shell\Open\Command from HKEY_CLASSES_ROOT, but I checked and the only subkey I have for the .pl extension is PersistentHandler. Will it still work, or do I need to manually add the key?

Update : It worked! :) I had to manually add a registry key for the .pl extension in HKEY_CLASSES_ROOT I created keys: Shell/ExecCGI /Command, then (this is the part the doc doesn't mention) I created a string named command and it's value was c:\xampp\xampp\perl\bin\perl.exe %1. Until the registry key was exactly right, it relied on the #! line. I used ScriptInterpreterSource Registry as recommended. I couldn't get it to work with Registry-Strict.
(End of Update)

Eventually, this entire application will need to go on an installation CD with an autorun.inf that will put everything in the right place. I'll figure that out. I can even create a .reg file, if necessary.

I do all of my development on Linux, when possible, and I , personally, am case-sensitive :)

--
-- GhodMode

For deploying scripts and sorting out the #! line, there's a trick:

perl -MExtUtils::MY -e 'MY->fixin(@ARGV)' *.pl
[download]

This is the same mechanism that make install uses for scripts: it will set the perl path to the right thing on Unix, and run pl2bat on Windows.

Concerning portability in general, you might be interested in the slides for a talk I have given on portability at two YAPCs.

In addition to what others have posted, I've found the single most aggravating thing about maintaining cross-platform sites is windows case insensitivity. Table names in MySQL and, of course, file names in the filesystem, can cause all sorts of grief.

My solution is to do all of the development on the Linux platform, then copy to the windows platform.

Scott

I have the info I need to get rid of my path separator variable and probably to stop editing the #! line every time I copy the code to Windows.

I can move my module to one of the standard directories from @INC.

I still have to edit my config. file when I move the code, though. That's actually not too much of a burden, but I think I may have found my solution in the %ENV variable SERVER_SOFTWARE: on the Linux server it shows Apache/2.0.55 (Unix) ... and on the Windows server it shows Apache/2.0.55 (Win32) ... ... That'll work :D

--
-- GhodMode

Perhaps you should use the $^O special variable instead, since it doesn't depend on a CGI environment.
It contains a descriptive name for the OS (e.g. "MSWin32" under Windows).


acid06
perl -e "print pack('h*', 16369646), scalar reverse $="

Dude!! You Rock!! That's what I was looking for in the first place :)

--
-- GhodMode

Or you can use the Config module, if you need more information about the system.

If you're using regular CGI's (and doesn't need mod_perl) you can use Cygwin at the Windows station, without problems. You will avoid annoyances with IIS, permissions or registry. But if you need mod_perl, just forget about. I recently (two weeks ago) had tried to use Apache 2 with Cygwin and it just didn't worked. Looking for answer at Google brought info related to wrong compilation problem and, well... I quit trying!

Alceu Rodrigues de Freitas Junior
---------------------------------
"You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill