|
Re: Dealing with incorrect shebang line entries on Windows with Apache
by xorl (Deacon) on May 04, 2005 at 15:44 UTC
|
You could do:
ln -s /usr/bin/perl /usr/local/bin/perl
Update: I'd also point out that development boxes should be exactly the same as the production box. Otherwise you get horrible problems like you're having | [reply] |
|
|
Thank you for your reply. Yes, that would work, but I was hoping for something we would do locally and not have to change the server. I agree, the dev boxes should be the same as production, but that's not going to fly around here in a long, long time. I forgot to mention that we're developing on WinNT and the server is on a Linux machine. That's one more wrinkle. :) I'll modify the original post to state this important fact.
Trent
| [reply] |
|
|
You're using WinNT... Are you using ActiveState's Perl? It ignores the path in the #! line.
Update: On second thought, the web server on your dev station might pay attention to it. Is there anyway you could tell your web server to use a specific Perl instead of looking at the #! line?
| [reply] |
|
|
Re: Dealing with incorrect shebang line entries on Windows with Apache
by dave0 (Friar) on May 04, 2005 at 16:00 UTC
|
The best idea is to ensure that your development environments are identical in configuration to your production server.
Your dev systems might have a few extra debugging tools, a nicer text editor, etc, but you'll run into far fewer issues if you at least keep your Perl installations identical. | [reply] |
|
|
Is that common, though? Installing Perl on a WinNT machine into /usr/bin/perl or whatever *nix path structure? I know there's nothing preventing it, I'm just wondering what the best practice is.
| [reply] |
|
|
No idea... all my Perl work has been in *NIX environments. Since you suggested that creating /usr/local/bin/perl locally was an option you had considered, I just assumed that your dev environment was also UNIX-like.
If you're dealing with multiple OS'es, it might be easiest to have your check-in and check-out scripts insert the correct path for that system, or to have your Makefile.PL do it for you as gellyfish suggested.
| [reply] |
|
|
Nope.
By *default* on unix, there is some version of perl in /usr/bin/perl. Generally a newer version of perl is a /usr/local/bin/perl or /home/zaz/my_perl. On windows, generally active state perl is installed at c:\perl\bin\perl , but cygwin installs perl at c:\cygwin\usr\bin\perl, which, if you are using cygwin's apache, you would call perl by /usr/bin/perl . If you use Oracle, you can use the oracle version of perl (not really recommended) at a path (similar to) /u01/oracle/some/version/export/bin/perl .
As far as development systems being different than production systems, in general, they almost are *always* different. Generally, older systems are used as development boxes, since they don't need the speed of production servers. (Also accept *slower* boxes, since there are times when you can't control the production environment, especially when you don't have root on the box.)
BTW. 300th post. :-)
| [reply] |
Re: Dealing with incorrect shebang line entries on Windows with Apache
by tlm (Prior) on May 04, 2005 at 16:03 UTC
|
#!/usr/bin/env perl
which may work for you in this case.
Update Added emphasis to the word "may" in response to merlyn's comment. :-)
| [reply]
[d/l] |
|
|
That's actually a dangerous practice, if you have multiple installs of Perl. Your PATH may not match my PATH, so we'll end up picking different Perl versions to run.
Also, env may not be on your box, and worse, I've seen machines where it's /bin/env instead of /usr/bin/env. Ooops!
| [reply] |
|
|
Good point. Being the main 'Perl guy' here at work, I have three installs of Perl. A couple others have two installs and the rest have just one install.
| [reply] |
Re: Dealing with incorrect shebang line entries on Windows with Apache
by gellyfish (Monsignor) on May 04, 2005 at 16:05 UTC
|
You could create a Makefile.PL that specifies the programs you want to install in EXE_FILES (you will also need to specify the correct location to install), this way the shebang will be changed to point to the perl that was used to run the Makefile.PL. See ExtUtils::MakeMaker for more details.
/J\
| [reply]
[d/l] |
|
|
So, in this instance, I would run the Makefile.PL after bringing all the code down to my local machine from CVS, and then again on the server after the changes and checking it back in to CVS?
| [reply] |
Re: Dealing with incorrect shebang line entries on Windows with Apache
by artist (Parson) on May 04, 2005 at 17:43 UTC
|
Just copy perl.exe to c:/usr/local/bin/perl.exe and it works without any problem.
| [reply] |
|
|
dude...
On your Win32 platform, why dont you bind .pl extension to your perl.exe ???
1. Right click a .pl file
2. Open With, Choose program
3. Browse for perl.exe
and voila !
i always use the standard #!/usr/bin/perl shebang line with win32 and never had any problems.
| [reply] |
|
|
It's required for Apache Web Server.
| [reply]
[d/l] |
Re: Dealing with incorrect shebang line entries on Windows with Apache
by barbie (Deacon) on May 06, 2005 at 10:55 UTC
|
Why not use the Apache directive that was exactly built for this. Look for:
ScriptInterpreterSource registry
in the httpd.conf file, and uncomment it. Hey presto, Apache reads the registry setting for the location of your perl interpreter :)
--
Barbie | Birmingham Perl Mongers user group | http://birmingham.pm.org/
| [reply]
[d/l]
[select] |
Re: Dealing with incorrect shebang line entries on Windows with Apache
by tohann (Sexton) on May 17, 2005 at 14:44 UTC
|
Thank you all for your suggestions. I've decided to go with the Apache configuration option. In order to do that I also had to associate .cgi file types with the Perl executable (.pl was already there), but that's minor. I was rocking after the conf file change and adding that association. Now it works like a champ and won't need a single change when moving code to and fro.
Thanks for your help!
Trent | [reply] |
