
The Long Death of CGI.pm - davorg
http://perlhacks.com/2015/12/long-death-cgi-pm/
======
rwmj
What's the strange bad-mouthing of Red Hat in this article? Upstream Perl
comes with dozens of modules in the base tarball, and the packaging just
splits that into separate RPMs so you can have more minimal installs. If you
really want to install all the modules from the upstream tarball, you install
_perl-core_ which is a meta-package that pulls in everything. You can install
CGI.pm either by:

    
    
        yum install 'perl(CGI)'
    

or by:

    
    
        yum install perl-core
    

and this works on Fedora and RHEL (I just checked).

The article claims it's _not really what you would recognise as Perl_ and Red
Hat _[strips] out many parts of Perl that they consider non-essential_ both of
which are plainly untrue.

~~~
davorg
Yes. And I mention both of those commands in the article.

The point is that the standard perl RPM does not contain everything that you
would expect to see in a Perl installation. And whilst I agree that it is
simple enough to fix that situation, many people running low-end web hosting
services don't realise that the standard Perl installation is stripped back
and don't do anything to rectify this - as demonstrated by the example in my
article.

I really don't mind Red Hat providing a standard stripped-down Perl RPM. I
just wish they had called it "perl-minimal" or something like that, saving the
name "perl" for the full Perl RPM.

~~~
rwmj
Well file a bug, I guess. The problem IMO is with the upstream Perl tarball
which contains an ever increasing set of modules. The RPM packaging is (also
IMHO) more rational.

The problem with dumb hosting providers is dumb hosting providers. I'm sure
they'll find other ways to screw things up even if the package name was
changed. Who uses web hosting these days anyway, when you can fire up a cloud
instance and install whatever you like?

~~~
davorg
> Well file a bug, I guess.

That's not going to fix Centos 6 and 7 - both of which are mainstream in the
web hosting industry right now.

And I've had this conversation with the Red Hat Perl packagers. They can't see
the problem.

> The RPM packaging is (also IMHO) more rational.

To be clear, I also like the way that Red Hat splits the Perl RPM into
individual RPMs for each module. My argument is only with the set of these
RPMs that are installed alongside the main perl RPM.

> Who uses web hosting these days anyway, when you can fire up a cloud
> instance and install whatever you like?

Not you and me, of course. But I'm talking about people with no technical
knowledge who rent some cheap web space and run a CGI guestbook program.

We could just ignore them. I suppose. Let them all switch to PHP. To be
honest, I think most of them have already gone down that route.

------
wtracy
TFA bad-mouths CGI, so let me ask: The only server-side technologies widely
available on shared-hosting providers seem to be CGI and mod_php. What else
are people supposed to use? Are you simply not worthy anymore unless you're
willing to spring for a VPS?

~~~
singingfish
Honestly, for low end stuff, mod_php is fine. I've just spent the day beating
some circa y2k perl code into submission on a modern shared hosting platform
too. That's sort of fine too (helps that I'm an expert and know how to make
debugging the PoS easy).

Wordpress is an OK product. On the other hand I reckon php is a bad technology
to stake your career on. Perl less so, bear in mind it's been around for
several waves of the latest greatest thing and is still going strong. Still I
quite enjoy javascript sometimes, it's like a syntactically crippled perl with
good vendor support. Perl6 looks cool, I hope I get the opportunity to mess
with its async stuff.

~~~
masklinn
> Honestly, for low end stuff, mod_php is fine.

Then again, so's GCI.

~~~
dspillett
Though all the forking of standard CGI makes it far less efficient, which is
quite a concern to a cheap shared hosting provider in a saturated market: they
need to cram as many accounts as possible on as few machines as possible to
have any hope of not running the business at a loss.

Fast_CGI helps here of course, but then you have your users needing to be able
to create long lived processes which moves the problem to one of memory use
and process cycling & other management.

~~~
singingfish
fwiw I'm currently working on tools to port a fastcgi perl cgi script to a
more modern infrastructure, for money. I'll try and work up the fun bits into
an article in due course.

------
calgoo
"At some point Perl 5.22 or one of its successors will make it into Red Hat
Enterprise Linux. And at that point we have a problem."

This made me laugh this morning, version 5.22 will probably be included in the
8.0 release? So we have a few years to go. RedHat 6.* is still running Perl
5.10 so no worries about anything breaking in the next 5> years.

Edit: formatting

~~~
gpvos
Further on, the article mentions that Red Hat actually already removed CGI.pm
from the default installation of RHEL 6, because they install a stripped-down
version of Perl.

~~~
rwmj
Which is nonsense. Red Hat split up the perl package so you can install the
modules separately.

~~~
davorg
It's not nonsense. That is what they do.

And, yes, it's easy enough to fix that (pointing that out was one of the main
points of my article). But we're talking about low-end web hosting services
where the web site owners don't have the root access to do that and the
service providers either don't know what is missing or don't care about Perl
enough to bother fixing it.

------
krylon
As long as CGI is still available from CPAN, I don't really mind.

But I still think CGI scripts have their place, and I have written a bunch
over the last two years at our company. I get that CGI has a number of
problems, but for simple tasks I think it's a completely acceptable solution.

(Just to be clear, I am talking of CGI as in "web server calling an external
program through a defined interface", not the HTML-generating stuff in Perl's
CGI module - my scripts use Template::Toolkit for generating HTML.)

------
dagurp
> There are good technical reasons for this. CGI is a dying technology. In
> 2015, there are far better ways to write web applications in Perl. We don’t
> want to be seen to encourage the use of a technology which no-one should be
> using.

I don't see the harm in including it. I would think it was enough to document
the disadvantages.

~~~
davorg
That was a conversation that was finished 18 months ago. I'm not sure that
anything can be gained by rehashing it. The best we can do is deal with the
consequences.

The discussion is at
[http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/ms...](http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/msg202130.html)
if you want the full details. But ultimately, I think they decided that having
the module in the core was tantamount to a recommendation for its use.

------
jayvanguard
I suppose you might want to use CGI.pm for some low level stuff but I find I
can still get most of what I need by copy and pasting stuff from Matt's CGI
scripts ([http://www.scriptarchive.com/](http://www.scriptarchive.com/)).

~~~
jasonjayr
Consider using the "Not Matt's Script" versions ([http://nms-
cgi.sourceforge.net/news.html](http://nms-cgi.sourceforge.net/news.html)), but
even that was last updated 2004. MSA was notorious for very bad examples of
old-style perl, and there are much better ways of doing perl nowadays.

For a much more modern approach, use Plack/PSGI, and one of the many
frameworks built using it.

~~~
davorg
The really galling thing is that Matt's scripts will continue to work find in
this post-CGI world. The nms versions were written to the best practices of
2000 and therefore need CGI.pm.

~~~
justinator
Actually Matt's stuff DOESN'T use CGI.pm (at least what I'm familiar with).
That was the thing - even when CGI.pm was the Better Practice, Matt didn't use
it.

No one should use Matt's stuff, unless you want huge security exploits.

~~~
davorg
> Actually Matt's stuff DOESN'T use CGI.pm

Yes. That's the point I was making.

------
brooklyndude
Is there anything I can't do in Swift? Perl is super cool, but Swift seems
like it can now be used on most of your text parsing and big data crunching
needs (DNA, lab R&D, etc) now.

And it was everyone's first web language in the day. I was super impressed
when ran my first perl script. I was hooked. :-)

~~~
dpe82
> Is there anything I can't do in Swift?

You can't do nostalgia for the good ol' days in Swift.

~~~
bigiain
Ahhh, do you remember back in May, before Swift 2 came out? Good times man!

(I remember when my first eCommerce site broke when my webhost upgraded from
Perl 4...)

