[perl]sub BEGIN {
my $path = $ENV{ PATH_TRANSLATED} ¦¦ $ENV{ DOCUMENT_ROOT};
$path =~ s/\\/\//g; # Change all '\' to '/'
$path =~ s/$ENV{ SCRIPT_NAME}$//;
$path =~ s/\//\\/g; # Change all '/' back to '\'
## Set current directory to web root
chdir( $path);
## Add project's /Perl directory to include path
$path =~ s/(.*)\\.*?$/$1/;
push( @INC, "$path\\perl");
}[/perl]
Basically I use IIS on my server, and Abyss on my laptop for development. Unfortunately, they have slightly different ideas about the default working folder, and each project has it's own folder for perl modules and this path need to be included.
Is there any way to get Perl to run this script without me having to include it at the start of EVERY cgi script?
#!/usr/local/bin/perl
#!/usr/local/bin/myperl
What would the myperl script look like?
This is why the shebang line is ignored on Windows.
You can also have a Windows Explorer file association for .pl files so they open in your editor, but that has no affect in IIS.
$dir ="../" or something?
Ever try using CWD? [perldoc.perl.org...]
It is more portable than using environ variables to grab the current path.
Second, why is this line in there:
$path =~ s/\//\\/g; # Change all '/' back to '\'
You shouldn't need to do that at all. Just leave them to foreslashes and let windows perl figure it out (it has no problem with them in paths and transparently transposes them).
Lastly, dump the iis under windows and start using Apache for windows. It will help you build much more portable code. (the code you are using right now that generated this page is running under redhat and 100% developed under windows xp/apache).
In Windows the association for perl files within the web server is set in IIS, and it's only read once at server boot up generally, not every time a script is executed.
(That is if you're running IIS, don't know about other web servers)This is why the shebang line is ignored on Windows.
You can also have a Windows Explorer file association for .pl files so they open in your editor, but that has no affect in IIS.
The association of perl within the server is a seperate issue. If they are using Windows with Apache the shebang line is not ignored unless you set the Apache directive that also ignores the shebang line and instead finds perl in a different way.
The shebang line is also ignored with command line scripts, not just the IIS server. It is ignored because windows just does not work that way, it uses file associations.
You can associate .pl files with the perl executable and perl will run them, not from the web server, but from the command line. If you want your .pl files to open in an editor you associate them with the editor and not perl.
[edited by: perl_diver at 5:32 pm (utc) on April 16, 2008]
You shouldn't need to do that at all. Just leave them to foreslashes and let windows perl figure it out (it has no problem with them in paths and transparently transposes them).
Just a side note: There is no transposing of the slash. Windows fully supports both back and forward slashes in paths, it has since day one I believe. You can use them in Windows itself no problem. DOS however does not.
all the stuff about file associations....
Yes, Perl_diver is correct, this is how it's set up on Windows.
Back to your path issue - can't you use a "relative" directory?
$dir ="../" or something?
The problem is, different servers set the cwd to different paths. Some to the script sub directory, some to the web root directory. There is a difference between Abyss and IIS hence the problem.
The code there effectively does a
..\\perlfrom the web root directory.
Second, why is this line in there:
$path =~ s/\//\\/g; # Change all '/' back to '\'
Cos I was lazy with my
$path =~ s/$ENV{ SCRIPT_NAME}$//; regex! :) no problem with them in paths and transparently transposes them
Yeah I knew that one. Thanks.
Lastly, dump the iis under windows and start using Apache for windows
I use IIS because I'm familliar with it. I'm not familliar with Apache. I tried it once - disasterous, couldn't get to grips with the config file. Does it have a GUI config program?
IIS also handles my FTP, does Apache also do that?
The one thing that worries me about switching is that there are a lot of people asking about configuration problems with it compared to IIS.
Understood - that is half of the battle.
> Does it have a GUI config program?
Not sure. I think there are some out there for it. However, once you get it setup, you shouldn't have to muck with it too much. I've not touched mine in YEARS.
> IIS also handles my FTP, does Apache also do that?
Nope. http/File serving is what apache is all about :-)
> configuration problems with it compared to IIS.
Just copy someone elses config file. There really is very little too it.
here [webmasterworld.com] is mine. I put apache in c:\apache
Everything else is defined in the virtual directives at the bottom.
I was kinda hoping there'd be some pm somewhere that Perl always executes on startup, but if not I'll create my own and stick a simple 'use' in my own scripts.
ActiveState Perl has such file, but I don't remeber it's name and from which version - serch it's documentation. Or you can compile Perl yourself with this option.
BEGIN is a reserved word
Yes, BEGIN is what you use when you want code to be executed at the program start -- in this case before processing the 'use' statements.
That's the point.
For ActiveState Perl it's C:\Perl\site\lib\sitecustomize.pl (or where you installed Perl).
Strawberry Perl is not compiled with this option.
Also look at FindBin module.
(btw: welcome to the board...thanks for joinging us)
you don't need 'sub BEGIN {}', write only 'BEGIN {}'
Thanks for the correction Chorny.
I've had a look in my C:\perl\site\lib (that is where my Perl is), there's no sitecustomize.pl, do I have to create one?
If it would not work - you can reinstall your Perl (ActiveState only), Perl 5.10 is very good, 5.8.8 also is good. It would require reinstalling all Perl modules. For 5.10 DBD::mysql can be installed from other repositories.
