mod_perl was always a pain to compile and work with on your own; in my experience, going back to 2000 or so; caveat to my opinion: I am sys-challenged. It was a smart and powerful tool but was always hard-wired to apache which back in the day was a reasonable choice but ultimately a bad design that kept it out of the shared hosting game. Sidenote: it was part of why Toys.com fell apart during its first Christmas rush, and why PHP took the web from Perl.

People recommend FastCGI because it’s the only decent option for Perl in many setups and shared hosting. I do not recommend it, mod_perl, or apache today. For Perl some sort of dedicated, agnostic, application server. I use uwsgi where I control the server, and nginx as the webserver. It speaks PSGI fine if launched and configured for it. There are other options but I do not know most of them well enough to discuss or recommend them except to say that, currently, uwsgi is superior to all the Perl-based solutions.

Short answer: no.

Longer answer: mod_perl is used to embed a perl interpreter into Apache and this allows for the creation of filters and handlers in Perl. That's an awesome feature and it's the only way to do this. However, BitD mod_perl was sold on the efficiency benefits of a persistent dynamic server so a large number of less well-informed people thought that this was the only reason to use it. With the advent of FastCGI, PSGI, etc. this becomes less of a reason to use mod_perl so that segement of the user base has generally migrated away. The core who use it for other purposes remain.

FastCGI, no longer downloadable from some servers (phased out already), seems to be promoted here; but I am left wondering where one obtains it?

From https://httpd.apache.org/download.cgi#mod_fcgid

A friend wants to run my scripts on his Windows computer.

Your friend might benefit from some persuasion regarding their choice of operating system ;-)

If you your friend really wants to run anything on MSWin32, they will probably require help specific to that O/S - at which point I am happy to leave the two of you to it. Best of luck!

I would tell my friend just to use the online versions of my scripts, but he is working with tribes up in the mountain regions where they have very poor cellular reception and no internet. He comes into town once in awhile and catches up with friends online before going back "out of contact." He needs my scripts to do some of his work--and he'll need to synchronize his work with the online server from time to time if others are to benefit by it (and if he is to have a good backup of it).

The link you provided looked vaguely familiar--sure enough, I'd been there already. There is no working make/cmake/nmake/gmake... on the Windows computer, so even this fastcgi option fails to install. In trying to use one of the 'make' options, I've seen errors including anything from not finding the apxs executable to having a recursive path (infinite loop) in the directory tree which stopped the process. Many, many "file not found" type of errors, in most cases of which the files actually exist on the system (not the case for the apxs executable).

It's been a good reminder for why I left Windows and never looked back. My friend claims he's forced by certain pieces of equipment into the Windows mold, as there are no Mac drivers for them. I certainly did promote Mac over Windows while he was here. Sadly, some are hard to persuade.

Blessings,

~Polyglot~

Strawberry Perl used to supply dmake, and now supplies gmake. Using that might at least solve the lack of a make.

> A friend wants to run my scripts on his Windows computer..

I fought a lot trying to run my (oldies) CGIs on windows Internet Information Services (IIS) and was always a pain. I tried with XAMPP and was a pain too.

Now what is left running on windows at $work was rewrote by me with Dancer2 and started at system startup via scheduled tasks with

# program to run                           # arguments to be passed to
C:\perl5.26-64\perl\site\bin\twiggy.bat    --listen 10.10.10.10:80 c:/
+scripts/MyAwesomeWebsite/bin/app.psgi
[download]

I have perl5.26-64 in PATH and after several tries I found Twiggy a good choice.

good luck

L*

Okay, I'm ignorant: Is IIS something like LAMP? I assumed it was something like a database system, and didn't think much of it. Could it actually be used in place of the Apache/MariaDB/mod_perl setup? All I was aware of was that I had to go in and change its port so that I could use port 80 with Apache.

Blessings,

~Polyglot~

Hello,

maybe I was not clear enough.. I will rephrase it:

avoid IIS as much as possible, dont even think IIS to be something useful for a perl programmer with Linux background

It would be easier to write your own preforking server than bind IIS to your will. Unfortunately IIS is my daily brad at $work, so in this case, my statement is ~autorithative :)

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Internet Information Services

So install Vagrant on the Windows computer. Then import a Linux image. Then you can use the package manager of the chosen Linux OS to install mod_perl.

Thank you. At this point, I'm willing to try most anything--and this may be the answer. I've always disliked Windows, and sure don't enjoy trying to get my perl scripts working in a WAMP environment.

But I want my friend to be able to simply access the scripts from his browser. I'm not sure if he's computer literate enough to open up a VM every time he wants to access them. In reading some of Vagrant's introductory materials, I wonder if I am understanding them correctly--as in, it sounds almost too good to be true. Is it really like having the server on your local machine such that, from Windows, you could SSH into the VM and you could access it via HTTP just as if it were an online server?

Blessings,

~Polyglot~

Yes, Vagrant makes it easy to do these things. SSH'ing into the VM - you get that out of the box. Accessing the HTTP services running in the VM from the browser requires some minor configuration to map ports in the VM to those in the host computer.

But once set up, it will be pretty much like browsing to a site on an online server.

mod_perl isn't needed to get scripts running under apache. From our brief conversation it doesn't sound like you're doing anything that really needs mod_perl, you'd definitely know if you were using it. The XAMPP stack includes apache, mariadb, perl/php etc, and is available as a single installer for Windows. If your goal is to provide something for someone else this may be an avenue worth exploring if you want to save them the trouble of setting these things up by hand.

... I tried everything ... Random tarball WinRAR ... waah ;) ...

strawberry perl -V:make tells you what your make is. But so would bin/cpan.... It would also take care of the tarball stuff<><>

cgi is a builtin choice but requirements really depends on your script

uwsgi https://uwsgi-docs.readthedocs.io/en/latest/Apache.html https://metacpan.org/dist/mod_perl https://uwsgi-docs.readthedocs.io/en/latest/PSGIquickstart.html

Windows searched the entire hard drive for me and could not find any filenames with 'make' in them. There was no make option at all until I had installed over 8 GB of downloaded Microsoft developer tools. (I didn't want so much, so actually had unchecked a number of the items initially, but found I had to go back and add more and still more to the list in the hopes of acquiring a 'make' option--until I finally did.)

I'm simply not at all familiar with Strawberry perl or its capabilities. It seems it doesn't mesh as well with Windows as ActiveState perl does, from what I've read. Maybe I'd still have more hair if I had chosen the latter?

Blessings,

~Polyglot~

I strongly recommend strawberry portable editions there is a launcher that simply temporary modifies your PATH and you are done.

Put the full path of perl in any aother cases (like mentioned above)

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

For what it's worth, I stopped the hair-pulling with Windows and went with the Virtual Machine suggestion. I installed VirtualBox, downloaded an image of the latest Ubuntu LTS, and worked with what was familiar to me in getting it setup as a LAMP server. In retrospect, I should probably have just done it that way from the outset, but I had thought it would be more convenient for my friend running more natively on Windows. Now he does need to start VirtualBox, click on the "Start" button for the VM, and then navigate to the local address for that server in his browser--but it's really not that difficult.

One minor nuisance to me, that won't apply to him, was in having to switch the VM's network setting back and forth between "NAT" and "Host-only Adapter" in VirtualBox, the former allowing the Linux VM access to the internet, and the latter allowing the Windows platform access to the VM. He won't need the internet, so he won't be having to toggle the setting.

Regarding Dancer2, the option sounds really intriguing, but alas, I have never been able to comprehend OOP-style references, etc., and have had poor luck in the past with the "guess and check" method of trying to use someone's module for my code. If they don't give very clear code examples that help me over the threshold, I never get in at the door. For this simple reason, I generally avoid using many of the "latest and greatest and most-widely touted" modules out there. I never developed sufficient abstract reasoning for Algebra 2 in high school, either, so I presume it's the sort of mental block that won't easily be erased (I tried to take Algebra 2 twice, with two different teachers, and ended up dropping both times as I just couldn't grasp it). I've managed to work with things like $cgi->param('form_input'); in my code--for me that's simple enough; but much beyond that I don't even seem to understand the explanations provided in the documentation, and, try as I might, I never seem to know what syntax is required to utilize some of these modules' features.

Blessings,

~Polyglot~

I used mod perl for a long time. However the trend (because IMO its far superior and more flexible and better performance) is to run HTTP servers within your code, rather than have HTTP servers call your code.

For example you can use AnyEvent::HTTPD to easily turn basically any perl script into its own webserver, to do whatever when you get requests. Nginx can then act as a proxy to it which seems to be the most popular way webservers are done now.