10 ms·

The Long Death of CGI.pm

33 points by davorg 11y ago

calgoo 11y ago
"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 11y ago
  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 11y ago
    Which is nonsense. Red Hat split up the perl package so you can install the modules separately.
    - davorg 11y ago
      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.
  - reacweb 11y ago
    They also removed CPAN which is a pain in the ass.
jayvanguard 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        > Actually Matt's stuff DOESN'T use CGI.pm Yes. That's the point I was making.
- ugexe 11y ago
  Please don't promote matts script archive. It is responsible for tons of terrible, out dated perl code due to its (previously) high search ranking.
brooklyndude 11y ago
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. :-)
- Moto7451 11y ago
  I'm a big fan of Swift 2.x and am doing most of my programming lately in either it or Perl. The two languages compliment each other very well. Lazy properties work as well in Swift as they do in Moose/Moo and handling options with the if let pattern fits well with the standard Perl if (my $var = ...) pattern. I can go on about some of the other things I've noticed but I'll leave it at those two. As such, I think the answer to your question is eventually you'll have the same depth is Swift that the Perl community has but so far Swift is still behind in tooling and libraries for many things. Since server side Swift on Linux is weeks old, there isn't a simple well known go to library for web work like CGI.pm, or my preference for simple web services, Web::Simple. And of course if Windows is something you need to support Swift won't help you.
- dpe82 11y ago
  > Is there anything I can't do in Swift? You can't do nostalgia for the good ol' days in Swift.
  - bigiain 11y ago
    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...)
- masklinn 11y ago
  > Is there anything I can't do in Swift? Web pages on shared hosts without a swift compiler, which would be more or less all of them?
  - 11y ago
wtracy 11y ago
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 11y ago
  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 11y ago
    > Honestly, for low end stuff, mod_php is fine. Then again, so's GCI.
    - singingfish 11y ago
      Yeah, but Plack::Request/Response is a better API to the same for low end stuff and will expand to bigger things as required.
    - dspillett 11y ago
      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.
rwmj 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      > 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.
dagurp 11y ago
> 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 11y ago
  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/msg202130.html http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/ms... 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.
krylon 11y ago
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.)
deleted 11y ago
[deleted]
amydav27 11y ago
,incase you need a hacker to track your cheating spouse,or change your grade,change exam score,change your identity,hack database,websites,iphone,tracking of ip address,gps locator, security jam,cctv hack,and lot more, kindly contact WALTSTEPH82 at GMAIL dot COM.or call/text +1 601 866 5203

33 points by davorg 11y ago

"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 11y ago
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 11y ago
  Which is nonsense. Red Hat split up the perl package so you can install the modules separately.
  - davorg 11y ago
    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.
- reacweb 11y ago
  They also removed CPAN which is a pain in the ass.

jayvanguard 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      > Actually Matt's stuff DOESN'T use CGI.pm Yes. That's the point I was making.
ugexe 11y ago
Please don't promote matts script archive. It is responsible for tons of terrible, out dated perl code due to its (previously) high search ranking.

brooklyndude 11y ago

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. :-)

Moto7451 11y ago
I'm a big fan of Swift 2.x and am doing most of my programming lately in either it or Perl. The two languages compliment each other very well. Lazy properties work as well in Swift as they do in Moose/Moo and handling options with the if let pattern fits well with the standard Perl if (my $var = ...) pattern. I can go on about some of the other things I've noticed but I'll leave it at those two. As such, I think the answer to your question is eventually you'll have the same depth is Swift that the Perl community has but so far Swift is still behind in tooling and libraries for many things. Since server side Swift on Linux is weeks old, there isn't a simple well known go to library for web work like CGI.pm, or my preference for simple web services, Web::Simple. And of course if Windows is something you need to support Swift won't help you.
dpe82 11y ago
> Is there anything I can't do in Swift? You can't do nostalgia for the good ol' days in Swift.
- bigiain 11y ago
  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...)
masklinn 11y ago
> Is there anything I can't do in Swift? Web pages on shared hosts without a swift compiler, which would be more or less all of them?
- 11y ago

wtracy 11y ago

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 11y ago
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 11y ago
  > Honestly, for low end stuff, mod_php is fine. Then again, so's GCI.
  - singingfish 11y ago
    Yeah, but Plack::Request/Response is a better API to the same for low end stuff and will expand to bigger things as required.
  - dspillett 11y ago
    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.

rwmj 11y ago

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 11y ago
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 11y ago
  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 11y ago
    > 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.

dagurp 11y ago

> 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 11y ago
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/msg202130.html http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/ms... 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.

krylon 11y ago

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.)

deleted 11y ago

[deleted]

amydav27 11y ago

,incase you need a hacker to track your cheating spouse,or change your grade,change exam score,change your identity,hack database,websites,iphone,tracking of ip address,gps locator, security jam,cctv hack,and lot more, kindly contact WALTSTEPH82 at GMAIL dot COM.or call/text +1 601 866 5203