Cross platform coding advice

[k_rajesh]

Good folks, I host my site with a provider who has Linux servers and Mysql database. I am more comfortable on windows... (sorry, I am!)... considering that I do not have anything but FTP access on the production servers, is it risky for me to develop on windows and deploy on linux? Perl-wise will there be any difference at all? One problem, I straightaway foresee is that some of the modules I use will not be available on the Linux machine... how can this issue be addressed if the provider is not willing to install the modules just for me? Are there any other issues that I need to be aware of?
Regards,
Rajesh

[Corion]

It's very easy to develop on Windows for Linux, as long as you keep that in mind. Under Windows, mostly there are features lacking, like proper fork(), selectable filehandles and some other stuff, so if you follow what is outlined in perldoc perlport, you should be mostly going. The main problems are when you're interacting with the operating system, and that is mainly by opening files.

• You should use all filenames in "unix notation", as Win32 understands the forward slash as path separator as well.
• For temporary files, use File::Temp instead of hardcoding the filename
• At the start of the program, change the directory to a known location. I often use the following snippet:

  use strict;
  use File::Basename;
  use lib 'lib'; # or maybe '/home/k_rajesh/perl5lib'
  chdir dirname $0;
  

• Keep all additional modules for your program in a directory under your "main program directory". If your main program has to live in a web-accessible directory, I recommend to launch it through a shell script from there, as that will keep your Perl code clean and your modules out of the web accessible space:

  #!/bin/sh
  exec '/home/k_rajesh/perl_prog/prog.pl'
  

For installing modules on the Linux host, that is very easy as long as the modules are written in Perl, see A guide to installing modules for Win32, especially the "Manual install" section. In most cases, you can simply unpack the module distribution and copy all files into your application lib directory in the right directories.

[nothingmuch]

Don't use forward or backslashes, instead use File::Spec or Path::Class:

use File::Spec; # could also use File::Spec::Functions
my $file_name = File::Spec->catfile(File::Spec->updir, qw/foo bar.txt/
+); # "../foo/bar.txt" on unix

# or

use Path::Class;
# these return Path::Class::File objects which can be used as strings
# and also have some convenient methods ($file->open, etc)

my $file_a = Path::Class->new()->parent->subdir("foo")->file("bar.txt"
+);
my $file_b = file(dir()->parent, "foo", "bar.txt');

[wazoox]

Another option is to run your own Linux system to test the scripts you developed. If you don't want to go thru the hassle of repartitioning drives, install Linux, rebooting, etc, you can use the fine QEMU emulator to run a linux system under windows. There are a lot of linux disks images available on the net (preconfigured complete linux system to run with qemu). You can also use a Linux LiveCD with QEMU, like Knoppix, DSL, etc.
I personnally use QEMU a lot to run windows on Linux :)

[techcode]

If you are writing "normal" web applications, that interact with MySQL (or some other RDBMS) you usually do not see the difference. I've been using Windows and 99.9% of my applications are deployed on Linux or FreeBSD.

Virtually only thing that was making problems to me is the newline character. You only need to make sure that first line (#!usr/bin/perl or similar) is on it's own. And since Windows and Linux have different line endings unless you save files in Unix mode it won't be the case.

As I'm using CGI::Application and many of it's plug ins - that aren't widely available on the plain hostings here's what I'm using :

In my root folder (htdocs or www usually) I have index.pl file which just calls CGI::Application::Dispatch run method. All other files are inside folder named by the application (say AppName). That folder is protected with .htaccess (just write "deny from all" inside of it). And inside of it I have :

Templates/
Templates/Module1/files.dwt
Templates/Module2/files.dwt
...
Foundation/ (modules inherithed by others)
Foundation/Database.pm
Foundation/Runmodes.pm (this one is use base '' in all Runmodes, and itself inhretihs from CGI::App)
...
Runmodes/
Runmodes/Module1.pm
Runmodes/Module2.pm
...
Config/ (some config files)
Cron/ (some scripts run by cron, delete old sessions ...etc)
CAPN/ (inside of it, there are all the modules that are from CPAN, but aren't available on the server. You need to add it to the @INC in the index.pl file)


Overall it works pretty good. Once I set it up on the server, I only upload files inside Runmodes and Templates folders (most of the time).

O yeah, templates are just plain HTML + HTML::Template tags, but are named *.dwt and not *.tmpl so Dreamweaver would open them nicely with WYSIWYG part working too.

[schweini]

i'd just like to add that the shebang line ( #!/usr/bin/perl ) was always a source of majot headaches for me, when i developed on apache on windows, and deployed to apache on linux. a simple solution is to create the directoy c:\usr\bin\ and simply copy perl.exe into it (or create /perl/bin/perl on the linux machine, and put a symlink to /usr/bin/perl there).
this avoids the trouble of changing the shebang every time you transfer something from OS to OS.
the 'newline problem' is easily worked around by adding a '--' to the sheband line:
#/usr/bin/perl --
which tells the perl interpreter that everything after the '--' is code, and not some weird command-line options. You shouldn't REALLY need to do that as long as you always FTP your files in ASCII mode, but sooner or later some FTP program will mess this up, and with the '--' you can edit the files on a samba share, and everyhting works.
hope that helped,
-schweini

[Tanktalus]

Just as a side note, but the first line is something that I'm trying very hard to always build into the script. That is, I would rather set up via Makefile.PL or Build.PL, and let them set the shebang line up appropriately. I admit to not working out all the kinks to the point where I can do this all the time, but it may be something to think about.

One of the advantages is that you start thinking of your application as something to be distributed. You also will end up in an environment where a source-code control system (SCCS) and/or version control system (VCS) will make sense, and will be easy to use. Of course, on Linux, cvs fulfills that easily since it's usually built-in. On Windows, cvs is supposedly easy to set up (SourceForge has instructions on how to do this when accessing their cvs servers).

Another advantage is simply that you end up with a "make dist" or "./Build dist" command that wraps everything up for you.

[schweini]

point taken - although the particular software i am developing gets distributed via rsync to the other servers.
speaking of CVS - is there a transparent filesystem-to-cvs thingy somewhere out there? i have gotten very used to my 'CTRL+S, perl -c, FTP, firefox-refresh, cp to production-code-dir' devel-cycle, yet would love to have versioning and all that, and some kind of CSV-filesystem-driver for windows and for linux would be great for that, i think...