1918 ANSI
1947 ISO
1970 Unix
1972 C
1974 TCP
1981 IP
1983 GNU
1985 POSIX
1985 C++
1987 Perl!
1988 Unicode
1989 Bash
1990 Python
1991 Linux
1991 HTTP
1991 HTML
1995 Apache
1995 Javascript
1995 Java
1995 Ruby
1995 PHP
1996 CSS
1996 mod_perl (Don't even be callin *me* old!)
[download]

CGI::Alternatives perpetuates all the common fallicies against CGI that if heeded only disempower independent developers. This includes advocating the replacement of all of Perl's wonderful and extremely simple, stable, mature, powerful CGI modules with vastly more byzantine "frameworks"¹ which rigidly enforce all sorts of corporate nonsense like "full separation of concerns"¹, total object-oriented lack of any possible function-ality, and the absurd complication of allowing oneself to be used by something as annoyingly totalitarian as templates¹ EVEN when they're not appropriate! All of these techniques have their place of course, mostly in big projects, with lots of tiny modules (to confuse management, ensure job stability, in competitive workplaces, stretching hours into months, for the children), but not usually in code written by us individuals for fun, prototyping, and extreme levels of pure: results.³

With all due respect to the author's efforts to change how we Perl into something his bosses find acceptable, the author of CGI::Alternatives is actually in charge of CGI.pm! How is this even possible? I realize the author is a talented programmer who has contributed significantly to CPAN, but this quote directly reflects his inappropriate state of mind towards the CGI paradigm (while CGI.pm is derided with that weird novelty-obsessed bigotry for being "old", as he removes perfectly sensible functions, only to prove his pointless point):

"You can't just hand a template to the web-designers and allow them to work their magic. Don't mix the business logic and the presentation layer. Just don't."

This guy doesn't even know what a CGI programmer does yet he dictates to us? This is CRAZY! We ARE the web-designers, OF the business logic, AND the presentation layer--ALL mixed together--like a SWISS ARMY CHAINSAW: this is our TECHINQUE! THIS IS Perl! Something YOU (Lee) obviously don't understand. Mixing it all up is exactly how some other language(s) seized the web from Perl (along with plenty of well-funded corporate FUD). Even though we still do it far better.

We have been here from the beginning and we remain no matter how many of our tools you try to disable or how much FUD you spread about our primordially awesome technique of producing ONE UNIFIED FILE, USING CORE MODULES, QUITE OFTEN VASTLY SUPERIOR TO FRAGMENTED TEMPLATES, WRITTEN BY ONE PERL GENIUS, RATHER THAN A TEAM OF HOPELESSLY ABSTRACTED CORPORATE DRONES: Because Larry wrote and maintains Perl that way; Blessed be.

How dare you tell us to stop doing what we love and what Perl empowers us to do? How dare you remove the HTML generation functions from CGI.pm? Who do you think you are anyway? People who come to Perl and say things have got to change don't appreciate Perl and should be led as far away from Perl as possible (Python), not in charge of (formerly, unfortunately) core modules!

Can someone who cares please take CGI.pm away from Lee Johnson (LEEJO)? I would feel far more comfortable with someone we can trust, like ikegami or Merlyn³, in charge of maintaining CGI.pm. At least we know they would give us what we want and need, and more, rather than inflicting torture by removing legacy functionality FOR EMOTIONAL REASONS thereby violating operational stability.

News for you Lee: What worked 20 years ago still works today: UNIX, POSIX, BASH, PERL, ME, AND MAYBE EVEN YOU. Mature technology never stops working! I appreciate innovation so don't necessarily stop trying to reinvent the wheel, but please do stop trying to shove your shiny new wheels in sheep's clothing down our throats because PERL ALREADY WON.⁴

If we stopped wasting time and spirit listening to ideologically driven flame warrior infiltrators who keep trying to change Perl we would already have a perfectly backward compatible and "fixed" (even though it has never failed me to this very day thank you Lincoln Stein⁵) CGI.pm on the corelist joined by other bits we desperately need and use EVERY SINGLE DAY like CGI::Carp, Data::Dumper and File::Slurp.

Some examples:

This extremely useful one-line CGI dubugger is now broken thanks to LEEJO (thanks!):

print header('text/plain'), Dumper $data; exit;
[download]

This is never ever going away:

start_html
[download]

CGI.pm now reduces efficiency by 100%!:

'</body></html>'
end_html # removed from CGI.pm, for ideological anti-reasons
[download]

If you agree PLEASE respond! If you do NOT agree please DO NOT hijack the thread because you guys already kinda won and I hope this thread can be for CGI programmers to chime in and support this seemingly lost cause which is really not even close to lost in the real non-ideological world of actual programmers who GET STUFF DONE.

Footnotes:

1. CGI::Alternatives
2. en.wikipedia.org/wiki/Common_Gateway_Interface
3. www.stonehenge.com/writing.html
4. programming.tudorconstantin.com/2015/01/perl-already-won.html
5. en.wikipedia.org/wiki/Lincoln_Stein

Revered Monks and dwellers of this venerated place,

I've been here for approximately two months now and I have no words to express my gratitude. The level of information shared here is amazing. The knowledge of the monks just blows my mind. Answers given here are of very high quality and I've come to realize that PerlMonks is the best place to learn Perl

Just wanted to take a moment to extend a heartfelt "Thank You" to all you knowledgeable and helpful folks here. Spending a few minutes here is far more enriching and fulfilling. The suggestions and advice given by you Monks has literally shaved off hours of time. I started with Perl due to its practicality and immediacy with which it naturally lends itself to real life problem solving, but now, I have started falling in love with this amazing language, all thanks to you folks.

This language deserves so much more attention and respect than it gets. All this talk of "Perl is Dead" now simply makes me wonder what the hell is going wrong with folks. This language will never die, because 1) its a pragmatic, practical and amazing language and 2)PerlMonks.

!prove -lr

The -l option is used to include your lib/

The -r option is used to find all tests in any children directories inside t/.

It really is just that simple. Furthermore, this is Universal, unlike using a wrapper and mapping actions to some vim command.

If you've never watched someone type a Perl script with voice recognition, it is enjoyable and painful at the same time:

https://www.youtube.com/watch?v=MzJ0CytAsec (~10mins)

I was a little surprised that in a recent thread no one seemed to flinch at code that was essentially the equivalent of $logged_in = $expect_pass=~/$FORM{pass}/i;.

If you happen to be wondering "Why is that bad?" - Because $FORM{pass} most likely comes from an HTML form (or at the very least could contain user input), and its contents will be interpolated into and interpreted as a regular expression, leaving the user free to input ".*", which of course matches anything, and so the user is always logged in!

One solution is to use /\Q$FORM{pass}\E/, which causes characters that would normally be special in a regular expression to be escaped - see quotemeta. In addition, the regex should probably be anchored, to prevent partial matches: /^\Q$FORM{pass}\E$/. Of course, in this example the much easier solution is to just use $expect_pass eq $FORM{pass} instead of a regex!

I feel like \Q...\E is forgotten too often when interpolating variables into regexes, and it seems to be often overlooked here on PerlMonks when people post code like the above. In fact, I see it forgotten often enough that I think instead \Q...\E should be everyone's default thought when interpolating variables into regular expressions, only to be left off when one has a good reason to (like dynamically building regexes - but of course doing that with unchecked user input is dangerous!).

So please, mind the meta(characters) and remember \Q...\E!

I'm the current maintainer of Cache::Memcached::Fast module, and I'm looking for someone to pass over this... uhm, privilege (which will include a transfer of both CPAN module and GitHub repo). C::M::F is written in C, so knowledge of C, POSIX, Perl XS, and familiarity with Memcached are required (plus PAUSE/GitHub accounts).

Volunteers please write to email listed at GitHub.

Thanks!

Hello, I've found out that CGI.pm is no more in the core distribution of Perl. I've also read that there are many better ways to implement a web application, like use Plack, or use CGI::Application, CGI::Snapp, Dancer, Mojolicious... It is also suggested to use templating systems (ok fine, I've used them with CGI.pm).

However, with modern responsive websites I think that CGI.pm is still a great module, so simple to use it that I don't see a reason to move away or use anything else.

You just write an API for the client javascript making an AJAX request and you're all done with something like:

#!/usr/bin/perl
use strict;
use CGI;
use JSON;
my $query = new CGI;
my $response = whatever(Query=>$query);
my $json = JSON->new->utf8(1)->pretty(1)->allow_nonref->encode($respon
+se);
print $query->header('application/json').$json;

sub whatever {

    # Here you can do REALLY anything, and send back an hash reference
}
[download]

Do I make it too easy? This is has a flat learning curve too.