Which Win32 distribution of Perl should I use: ActiveState, Strawberry, or both?

[Lady_Aleena]

On Wednesday something killed Windows on my old drive, so I started in on the install of the new one that we had lying around waiting to be installed. I am almost done getting everything just so on it but found a problem with how Strawberry set up Perl.

Ages ago I set up Perl on my computer using ActiveState Perl. Something about it bothered me, so after a long discussion about it here and elsewhere, I decided to install Strawberry. I had thought that I had gotten all of ActiveState uninstalled, but apparently I didn't.

Within the last couple of months, I had set up Apache so that I could test my scripts in my browser. Everything was working well. My scripts were displayed in my browser, and I was enjoying my successes and even some of my failures. (Sometimes failing is a good thing, it can lead to new insights.)

Now, with this new hard drive, I did fresh installs of all of the software just to keep the clutter down. However, Strawberry and ActiveState do not set up Perl the same. Now, I don't know what I want to do here.

1. Just use Strawberry, but go through all of my scripts and change I don't know how many shebangs to make it work (along with changing a few other things like the new root directory). Also, dig into my computer's configuration to get how Perl scripts run sorted out.
2. Uninstall Strawberry and install ActiveState so that I don't have to change all of those shebangs and hope that ActiveState sets up the computer the way it was with the old drive with a few minor exceptions of things I did separate of both installs.
3. Have both on the computer and see if there is a best of both worlds scenario.
4. Uninstall Strawberry and reinstall it using a custom directory to match what I already have in my scripts.

I am on the proverbial fence here. I just don't which "yard" to jump into. Any thoughts?

Update: Add fourth option which I am now considering.

[Burak]

Associate .pl|cgi (and whatever you need) with the related perl.exe. Then, add this to your httpd.conf:

ScriptInterpreterSource registry

[BrowserUk]

I'm confused. Windows doesn't use shebang lines to find perl so why would you need to change them?

Unless you're also using Cygwin. In which case: don't do that!

[Lady_Aleena]

I need accurate shebang lines for my scripts to properly load in a browser. Without a shebang or a bad shebang, I get an internal server error when I go to load the script.

[BrowserUk]

Ah! In that case, I'd use Junction to create a symlink that points your current shebang line at the new location of whichever perl installation you want to use with Apache.

This has the added advantage that you can switch between installations, or to a new installation, at any time, using a single command.

[rubasov]

I have never used Apache on Windows, but if I recall right what I've read, Apache can be set up to ignore the shebang and use the registry instead to find the interpreter. That way you can omit the shebang or even better use a Unix-compatible shebang. If you do that Windows, Apache on Windows and Unices all will be happy with your scripts without any change in the shebang line. So for example you can upload your scripts to a standard Linux hosting without change (if the other parts are already portable).

Have a look at the ScriptInterpreterSource Apache configuration directive.

Probably you also need to set the corresponding registry key if it does not exist already.

I hope this helps.

[PeterPeiGuo]

That is just fine. It's the common practice to have that shebang for Apache.

[PeterPeiGuo]

Apache httpd uses shebang to find the perl binary.

[frd1963]

True, windows doesn't use Shebangs, but Apache is what needs to decide how to run a cgi script, and it does use Shebangs.

[Anonymous Monk]

$ help ftype
Displays or modifies file types used in file extension associations

FTYPE [fileType[=[openCommandString]]]

  fileType  Specifies the file type to examine or change
  openCommandString Specifies the open command to use when launching f
+iles
                    of this type.

Type FTYPE without parameters to display the current file types that
have open command strings defined.  FTYPE is invoked with just a file
type, it displays the current open command string for that file type.
Specify nothing for the open command string and the FTYPE command will
delete the open command string for the file type.  Within an open
command string %0 or %1 are substituted with the file name being
launched through the assocation.  %* gets all the parameters and %2
gets the 1st parameter, %3 the second, etc.  %~n gets all the remainin
+g
parameters starting with the nth parameter, where n may be between 2 a
+nd 9,
inclusive.  For example:

    ASSOC .pl=PerlScript
    FTYPE PerlScript=perl.exe %1 %*

would allow you to invoke a Perl script as follows:

    script.pl 1 2 3

If you want to eliminate the need to type the extensions, then do the
following:

    set PATHEXT=.pl;%PATHEXT%

and the script could be invoked as follows:

    script 1 2 3

$ help assoc
Displays or modifies file extension associations

ASSOC [.ext[=[fileType]]]

  .ext      Specifies the file extension to associate the file type wi
+th
  fileType  Specifies the file type to associate with the file extensi
+on

Type ASSOC without parameters to display the current file associations
+.
If ASSOC is invoked with just a file extension, it displays the curren
+t
file association for that file extension.  Specify nothing for the fil
+e
type and the command will delete the association for the file extensio
+n.

http://stackoverflow.com/questions/2036577/how-do-i-ignore-the-perl-shebang-on-windows-with-apache-2 http://stackoverflow.com/questions/1846176/how-do-i-setup-strawberry-perl-in-msys http://stackoverflow.com/questions/1095309/writing-a-portable-command-line-wrapper-in-c

[Lady_Aleena]

Anonymous Monk...That was exactly what I needed. Thank you so very much for researching that for me. I knew I had to do something like that, I just couldn't remember the commands. With the solution above, I am all set up now. I just wish I knew who the saver of sanity is.

[petr999]

The best for Web applications on windows is, I think, the Cygwin's Perl. I was much impressed of how smooth the fork()ed loaded application works in FastCGI ( FCGI::Spawn, FCGI::ProcManager, etc. ) environment and, probably, the same should go here for cygwin's mod_perl against any other mod_perl.

But to write the desktop applications with WinForms, etc. my personal choice is the ActiveState's Perl. I find it easy with WxPerl to provide the compiled binary for the plain Windows user. ( WxPerl uses native forms for windows, same should go here about Tk and Gtk Perl bindings ). You may do desktop applications with Cygwin also, but this should require the ( Cygwin's ) X server on the client, which may appear troublesome for the end user and less efficient in terms of widgets performance.

To accomplish the both tasks between the times, you may install both of those perls beforehand, but be careful from their interference, the $PATH environment variable at first and at least: I use Cygwin's perl from Cygwin.BAT shell only.

[PeterPeiGuo]

Active State is a bit too commercial to fit Perl's taste. You cannot even find their Perl download without filtering all the noise.

[Anonymous Monk]

http://downloads.activestate.com/ActivePerl/releases/

[PeterPeiGuo]

Thanks ;-) but that wasn't my point.

[roboticus]

Lady Aleena:

Since BrowserUk already mentioned cygwin earlier, I'd suggest giving it a try (unless you've already tried and dismissed it.) I've never used it for web apps, but I've been pretty happy with it for the last six years. I briefly tried ActiveState and Strawberry, but didn't keep them very long. (I don't recall why I uninstalled them, it could simply be that I saw no advantage to them over cygwin for my purposes...)

...roboticus

[sundialsvc4]

My experience using Strawberry has been quite uneventful. It is very much like the Linux and OS/X environments that I am more-generally used to.

Nevertheless, I also feel like I understand the slightly-different business objective that the ActiveState team is shooting for. And as such, they seem to be doing well. I really don't think that the two approaches can be reconciled (it would kind-of defeat the purpose, of both of them, at once). Both teams seem to know what they are going for, and both of them seem to be doing a top-flight job serving their particular audiences.

I guess it really depends upon how your business objectives sync-up with what ActiveState is trying to do; what your personal comfort/expertise level is. Are the particular things that “they are trying to make easy,” and is the particular way that they are trying to do it, “good with” what you are trying to do here? That's really what your decision will consist of.

“It's all Perl. Therfore, it's all good.™”