[32302] in Perl-Users-Digest
Perl-Users Digest, Issue: 3569 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Dec 15 18:09:25 2011
Date: Thu, 15 Dec 2011 15:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 15 Dec 2011 Volume: 11 Number: 3569
Today's topics:
CGI alternatives/replacements <justin.1111@purestblue.com>
Re: CGI alternatives/replacements <rweikusat@mssgmbh.com>
Re: CGI alternatives/replacements <ben@morrow.me.uk>
Re: CGI alternatives/replacements <cartercc@gmail.com>
Re: CGI alternatives/replacements <tadmc@seesig.invalid>
Re: CGI alternatives/replacements <stevem_@nogood.com>
Re: CGI alternatives/replacements <ben@morrow.me.uk>
Re: Problem configuring OS/2 for installing CPAN packag <nospam-abuse@ilyaz.org>
Re: Question on using perl in a cgi script <tadmc@seesig.invalid>
Re: Question on using perl in a cgi script <cartercc@gmail.com>
Use of uninitialized value: when don't you get that? (Tim McDaniel)
Re: vi regex to preserve interior commas in CSV string <cartercc@gmail.com>
Re: vi regex to preserve interior commas in CSV string <tadmc@seesig.invalid>
Re: vi regex to preserve interior commas in CSV string <cartercc@gmail.com>
Re: vi regex to preserve interior commas in CSV string <tadmc@seesig.invalid>
Re: vi regex to preserve interior commas in CSV string <cartercc@gmail.com>
Re: vi regex to preserve interior commas in CSV string <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 15 Dec 2011 15:06:23 +0000
From: Justin C <justin.1111@purestblue.com>
Subject: CGI alternatives/replacements
Message-Id: <f0fpr8-vpr.ln1@zem.masonsmusic.co.uk>
I visited a perl irc channel recently to try to get a quick answer to a
problem, the solution was found eventually. Part of the discussion led
to the suggestion that I shouldn't be using CGI.pm, but one of the web
frameworks: Catalyst, CGI::Application, Jifty, Continuity, Mojolicious,
Dancer, etc.
I don't find irc the best medium for a decent discussion, it's not easy
for people to reply with well considered thoughts, just snippets and
sound-bites, so I thought I'd ask about these web-frameworks here.
Has CGI.pm come to the end of it's usefulness? The company intranet site
has about a dozen or so pages, a couple of them static HTML ... but
using CGI to ensure consistent styling (CGI does the start and end html
stuff, between that is sub that opens the page body and prints that to
the browser). I can see that if I were to start this task again I would
do it differently, perhaps use a web-app, and the whole site driven by
one cgi - instead of clicking a link for, say, prospect management and
being taken to a page that actually manages that, having the web-app
return the functions needed for that choice. At least, that's what I
understand these frameworks to enable, and how the web-apps work.
Have I got that right? I know TMTOWTDI, but what is the 'usual' way
these days?
Justin.
--
Justin C, by the sea.
------------------------------
Date: Thu, 15 Dec 2011 15:53:20 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <8739clygpb.fsf@sapphire.mobileactivedefense.com>
Justin C <justin.1111@purestblue.com> writes:
> I visited a perl irc channel recently to try to get a quick answer to a
> problem, the solution was found eventually. Part of the discussion led
> to the suggestion that I shouldn't be using CGI.pm, but one of the web
> frameworks: Catalyst, CGI::Application, Jifty, Continuity, Mojolicious,
> Dancer, etc.
>
> I don't find irc the best medium for a decent discussion, it's not easy
> for people to reply with well considered thoughts, just snippets and
> sound-bites, so I thought I'd ask about these web-frameworks here.
I think you have answered your own question: These frameworks are
'marketed' by people who cannot (and couldn't care less for)
expressing their own thoughts in a consistent and clear way. That's a
large grain of salt going with their 'opinions'.
------------------------------
Date: Thu, 15 Dec 2011 16:46:00 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: CGI alternatives/replacements
Message-Id: <8rkpr8-n9h.ln1@anubis.morrow.me.uk>
Quoth Justin C <justin.1111@purestblue.com>:
> I visited a perl irc channel recently to try to get a quick answer to a
> problem, the solution was found eventually. Part of the discussion led
> to the suggestion that I shouldn't be using CGI.pm, but one of the web
> frameworks: Catalyst, CGI::Application, Jifty, Continuity, Mojolicious,
> Dancer, etc.
>
> I don't find irc the best medium for a decent discussion, it's not easy
> for people to reply with well considered thoughts, just snippets and
> sound-bites, so I thought I'd ask about these web-frameworks here.
>
> Has CGI.pm come to the end of it's usefulness? The company intranet site
> has about a dozen or so pages, a couple of them static HTML ... but
> using CGI to ensure consistent styling (CGI does the start and end html
> stuff, between that is sub that opens the page body and prints that to
> the browser).
There are two entirely separate questions here:
- How does my program receive requests from, ultimately, the user's
browser?
- How do I construct my responses?
You can use CGI.pm for both of these, or you can use it for one and not
the other, or you can use it for neither.
With regards to the second (constructing responses), I would never
recommend anyone use the functions in CGI.pm. It is far cleaner to keep
your HTML/CSS/JS/whatever separate from your Perl. Personally I would
use TT2 (the Template Toolkit, Template.pm), since I'm familiar with it
and it has a good balance of flexibility where it's needed without being
a complete programming language.
Other people may use other solutions: there are other templating modules
with more or less ability to put logic in the template (HTML::Template
and Template::Simple in one direction and Mason in the other come to
mind); there's the whole XML/XSLT/XHTML toolchain; I'm sure there are
others. Any of these solutions is, IMHO, better than putting
HTML-generating code in with your main program logic.
> I can see that if I were to start this task again I would
> do it differently, perhaps use a web-app, and the whole site driven by
> one cgi - instead of clicking a link for, say, prospect management and
> being taken to a page that actually manages that, having the web-app
> return the functions needed for that choice. At least, that's what I
> understand these frameworks to enable, and how the web-apps work.
As for the first question (receiving requests), using genuine unmodified
CGI (with a fresh invocation of perl per request) is quite rare
nowadays. It's considered to be extremely inefficient, especially since
modern Perl style tends towards using lots of modules, many of which
tend to take a long time (relatively speaking) to load.
The usual approach, instead, is to have a single persistent perl
interpreter (or, commonly, a small handful) which handles all the
requests and dispatches them to the appropriate code. There are many
ways of doing this: mod_perl, where the interpreter is built into your
Apache instances; FastCGI, where a separate perl process communicates
with the web server over a socket; one of several high-performance HTTP
servers written entirely in Perl, with or without Varnish or nginx or
something similar in front; or again, there are other options I've
forgotten.
CGI.pm supports FastCGI (and, IIRC, mod_perl) internally, so it's
possible that evn though you're using CGI.pm you're actually using one
of these more-efficient mechanisms without realising it. Even so, there
are necessarily problems (both in terms of efficiency and in terms of
managing the code) when you have multiple scripts which are all
logically part of the same application. Even when CGI was the only
interface available, it was considered good practice to put all the
significant code for a set of interacting scripts in a module (or
modules), and then have the entry-point scripts simply call into the
module. The persistent-interpreter approach just removes the need for a
whole lot of nearly-empty .cgi files.
Given this variety, IHMO the only sensible approach for new apps is to
(directly or indirectly) use PSGI. This is a standard (like the CGI
standard) rather than a module (like CGI.pm), but unlike CGI it is a
Perl-level standard for an interface between 'modules that are/know how
to talk to web servers' and 'code that wants to use such modules'. If
your program uses the PSGI interface, you can slot in a CGI interface,
or a FastCGI interface, or a simple-minded HTTP server interface for
testing, or whatever, without changing the application code. Most of the
frameworks you mentioned above are starting to use PSGI underneath.
(One note: PSGI, as I said, is a standard. There is a PSGI distribution
on CPAN, but it only contains documentation. The usual concrete
implementation of PSGI is called Plack, so if you want to write against
PSGI directly you end up using modules like Plack::Request.)
> Have I got that right? I know TMTOWTDI, but what is the 'usual' way
> these days?
For a larger job (anything that might reasonably be called an
'application'), I would use Catalyst, because I know it and it works
extremely well. I believe Dancer and Mojo are supposed to be lighter-
weight alternatives, in that it takes less time and less code to get to
a working app, but I haven't used them.
For small jobs, the sort that might once have been written as a single
CGI script, I quite like using Plack::{Request,Response} directly. The
documentation says they're too low-level for app code to use, and that
is true to an extent, but if you just want to do one small job that
hardly matters.
Ben
------------------------------
Date: Thu, 15 Dec 2011 09:36:00 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <f9a0c2d9-8447-4555-807d-2251061e2138@h11g2000yqd.googlegroups.com>
On Dec 15, 10:06=A0am, Justin C <justin.1...@purestblue.com> wrote:
> Has CGI.pm come to the end of it's usefulness?
I've used CGI.pm since around 1999 to build many web sites. In the
past several years, I've used it extensively at work to build
graphical interfaces to databases. FWIW, here's my opinion.
I have never, repeat never, used CGI to construct outgoing HTML. I
write the HTML by hand, typically putting it into a module in the
application directory named HTML.pm, and write the HTML fragments
using qq(), here docs, or similar, sometimes just using print(). I
started doing this in the beginning because I was frustrated
integrating CSS and JavaScript with CGI, and it was just easier for me
to do it this way.
For my database connections, I typically write a module called SQL.pm,
and call that as well. For the programmatic aspects, I write a module
named after the application, and call that as well.
I have never used anything other than CGI to handle HTTP requests in
my scripts, and I've never had a complaint.
My web apps wind up looking a lot like this:
use strict;
use warnings;
use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);
use HTML;
use SQL;
use APP; #this is my program code
use DBI: #if needed
use Mail::Sendmail #if needed
use MIME::Lite #if needed
use PDF::API2 #if needed
...
my $what =3D param('what');
...
elsif($what eq 'Request Employee Data')
{
my $queryresults =3D SQL::employee_select($what); #returns hash ref
my $returnvalues =3D APP::employee_select($queryresults); #builds data
my $formattedoutput =3D HTML::employee_select($returnvalues); #returns
HTML as a string
}
...
else { $formattedoutput =3D HTML::default_page(); } #user didn't make
any request
#main logic
HTML::print_header(...);
HTML::print_body($formattedoutput);
HTML::print_footer(...);
exit(0);
Obviously, there are better ways to do this, using dispatch tables is
one that I am presently experimenting with, but this has worked well
for me in that it's conceptually simple, easy to write, easy to
maintain, modular, and reliable.
Monday of this week, I bashed out a web app in about eight hours
(using SQLite) mostly without having to refer to any documentation,
using exactly this kind of structure. If you do it a lot, as I have,
you can do it with your eyes closed. I'm sure that a seasoned .NET
programmer using Visual Studio could probably do it in half the time,
but the typical PHP or ColdFusion guy would take twice as long, and
IMO Perl/CGI beats them all for cost, reliability, and simplicity.
CC
------------------------------
Date: Thu, 15 Dec 2011 12:05:57 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: CGI alternatives/replacements
Message-Id: <slrnjekdvm.53g.tadmc@tadbox.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
>
> My web apps wind up looking a lot like this:
>
> use strict;
> use warnings;
> use CGI qw(:standard);
> use CGI::Carp qw(fatalsToBrowser);
You should never enable fatalsToBrowser in production code,
as it has the potentical of helping crackers.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Thu, 15 Dec 2011 11:00:53 -0800
From: Steve May <stevem_@nogood.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <7wrGq.18288$U16.10057@newsfe15.iad>
On 12/15/2011 08:46 AM, Ben Morrow wrote:
>
> Quoth Justin C<justin.1111@purestblue.com>:
<snip>
>> Have I got that right? I know TMTOWTDI, but what is the 'usual' way
>> these days?
>
> For a larger job (anything that might reasonably be called an
> 'application'), I would use Catalyst, because I know it and it works
> extremely well. I believe Dancer and Mojo are supposed to be lighter-
> weight alternatives, in that it takes less time and less code to get to
> a working app, but I haven't used them.
>
> For small jobs, the sort that might once have been written as a single
> CGI script, I quite like using Plack::{Request,Response} directly. The
> documentation says they're too low-level for app code to use, and that
> is true to an extent, but if you just want to do one small job that
> hardly matters.
>
I've been fooling around with cgi scripts for years, and though I've
played with Catalyst I've yet to construct more than simple test apps.
The learning curve is a bit steep and I'm still getting a handle on
using and deploying it, but Catalyst *is* delightfully perlish compared
to the Rails straight jacket. :-)
I already owe you a Pint for your post, but just out of curiosity, could
you indulge me by passing on your thoughts on what constitutes "anything
that might reasonably be called an 'application'"
TIA,
Steve
------------------------------
Date: Thu, 15 Dec 2011 22:48:53 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: CGI alternatives/replacements
Message-Id: <l3aqr8-4qk.ln1@anubis.morrow.me.uk>
Quoth Steve May <stevem_@nogood.com>:
> On 12/15/2011 08:46 AM, Ben Morrow wrote:
> >
> > Quoth Justin C<justin.1111@purestblue.com>:
>
> <snip>
>
> >> Have I got that right? I know TMTOWTDI, but what is the 'usual' way
> >> these days?
> >
> > For a larger job (anything that might reasonably be called an
> > 'application'), I would use Catalyst, because I know it and it works
> > extremely well. I believe Dancer and Mojo are supposed to be lighter-
> > weight alternatives, in that it takes less time and less code to get to
> > a working app, but I haven't used them.
> >
> > For small jobs, the sort that might once have been written as a single
> > CGI script, I quite like using Plack::{Request,Response} directly. The
> > documentation says they're too low-level for app code to use, and that
> > is true to an extent, but if you just want to do one small job that
> > hardly matters.
>
> I've been fooling around with cgi scripts for years, and though I've
> played with Catalyst I've yet to construct more than simple test apps.
>
> The learning curve is a bit steep
Yes, it is, isn't it? It took me a little while to get my head round all
the necessary concepts to get started, though of course once you *do*
get to that point it all pays off since you've already done a lot of the
hard work.
My understanding is that this is exactly what 'lighter' frameworks like
Mojo and Dancer are supposed to address: getting to 'hello world' is
meant to be much quicker. I rather suspect that on a project of any size
the complexity has to go somewhere, and it just ends up finding its way
in later, but I've never used them in anger so I don't know.
> and I'm still getting a handle on
> using and deploying it, but Catalyst *is* delightfully perlish compared
> to the Rails straight jacket. :-)
>
> I already owe you a Pint for your post, but just out of curiosity, could
> you indulge me by passing on your thoughts on what constitutes "anything
> that might reasonably be called an 'application'"
I think I really mean anything with multiple pages in a 'flow':
certainly anything with any per-user or per-session state, and probably
anything with a database behind it. The sort of thing I would do in raw
PSGI would be, say, a little script to serve picture files slowly for
testing purposes, or a simple form-to-mail script, or something like
that.
Ben
------------------------------
Date: Thu, 15 Dec 2011 20:32:44 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <slrnjekmbc.18k.nospam-abuse@panda.math.berkeley.edu>
On 2011-12-14, Ben Morrow <ben@morrow.me.uk> wrote:
>> t/io_poll..........FAILED test 3
>> Failed 1/10 tests, 90.00% okay
> This doesn't worry me much. The test is testing that poll(2) works on
> STDOUT, which is a pipe, and it's already skipped on Win32, NetWare, VMS
> and BeOS because those OSs have a poll(2) which only works on sockets. I
> suspect the same is true of OS/2, and it simply needs to be added to the
> list of OSs to skip.
Such things are properties of CRT libraries, not OSes. I would not be
surprised if this test passes on OS/2 + EMX.
Ilya
------------------------------
Date: Thu, 15 Dec 2011 09:21:05 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Question on using perl in a cgi script
Message-Id: <slrnjek4ai.4g3.tadmc@tadbox.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
> my $what = param('what');
> #present HTML form unless 'draw' is clicked
> unless ($what eq 'draw')
> {
> print qq(<html><body><form><input type="submit" name="what"
> value="draw" /></form></body></html>);
> }
> #draw lines from file if 'draw' is clicked
> elsif ($what eq 'draw')
> {
> print qq(<html><body>);
> open DRAW, '<', 'draw.txt' or die "$!";
> while (<DRAW>) { print $_; }
> close DRAW;
> print qq(</body></html>);
> }
> else
> {
> print qq(<html><body><h1>ERROR!</h1></body></html>);
> }
The else clause is unreachable, so it should not be there.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Thu, 15 Dec 2011 09:54:56 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Question on using perl in a cgi script
Message-Id: <fca21e4e-be68-49f8-9124-ca8c476e9c56@f11g2000yql.googlegroups.com>
On Dec 15, 10:21=A0am, Tad McClellan <ta...@seesig.invalid> wrote:
> The else clause is unreachable, so it should not be there.
Yeah, and I also left out the
print "Content-type: text/html\n\n";
line as well. So, just regard it as what I said it was, a hypothetical
script written in Perlish pseudocode.
CC.
------------------------------
Date: Thu, 15 Dec 2011 21:19:23 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Use of uninitialized value: when don't you get that?
Message-Id: <jcdo8q$doi$1@reader1.panix.com>
I like to have "use strict" and "use warnings" (actually, "-w" on my
scripts). I'm now wondering: when can you use an undefined value and
not get the "Use of uninitialized value" warning. Experimentally, I
don't get the warning with
my $x = undef;
my $y = undef;
if ($y) { ... }
if (! $y) { ... }
if ($y && ! $y) { ... }
if (exists $x->{notdef}) { ... }
if (defined $x->{notdef}) { ... }
if ($x->{notdef}) { ... }
# and none of those autovivify it.
(at least under Perl 5.008008, which is what my workplace uses).
Is there a more complete listing of conditions that cause the warning
and/or those that do not? I consider "using the value" to be an
insufficient explantion, because I consider "if ($y)" to be a use of
the value. "Using the value with an operator" covers cases like "+"
and "." and "eq", but it doesn't work for me because "&&" is an
operator too.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 15 Dec 2011 06:35:25 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <7ffddeaa-794c-4a49-a93d-7f44d3cf27f4@s26g2000yqd.googlegroups.com>
On Dec 14, 5:16=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> What was your Perl question?
Didn't have Perl question. I posted to comp.editors and cross posted
to clpm because of my high regard for the knowledge, intelligence, and
experience of the denizens of clpm, you included, Ben.
I have also noted from time to time that people sometimes post on
comp.editors and clpm, and that some of them us vi/vim and have a deep
knowledge of it. I had hoped to catch the eye of some of these people
and maximize the chance of getting an answer.
Sorry if this offends you, but it's not a flame or a troll, and the
subject of the post clearly discloses that it's a vi question.
Thanks, CC.
------------------------------
Date: Thu, 15 Dec 2011 09:17:20 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <slrnjek43h.4g3.tadmc@tadbox.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
> On Dec 14, 5:16 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>> What was your Perl question?
>
> Didn't have Perl question. I posted to comp.editors and cross posted
> to clpm because of my high regard for the knowledge, intelligence, and
> experience of the denizens of clpm, you included, Ben.
This isn't about what you want.
It is about what the readers of clpmisc want.
That is, questions about Perl.
> I had hoped to catch the eye of some of these people
> and maximize the chance of getting an answer.
So, you were unconcerned about what clpmisc people wanted.
You just really really wanted an answer to your vi question?
> Sorry if this offends you,
All abuses of Usenet are offensive.
Your abuse here displays a rather profound selfishness on your part.
> subject of the post clearly discloses that it's a vi question.
Stating that a post is off-topic does not give license to post it
to non-related newsgroups.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Thu, 15 Dec 2011 08:20:03 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <e6d8caf5-9789-4633-b431-23f3706da811@t38g2000yqe.googlegroups.com>
On Dec 15, 10:17=A0am, Tad McClellan <ta...@seesig.invalid> wrote:
> All abuses of Usenet are offensive.
I did not abuse Usenet.
> Your abuse here displays a rather profound selfishness on your part.
Actually, your abuse displays a rather profound selfishness on your
part.
As an aside, permit me to say that the regex engines in Perl and vi/
vim have a number of substantial differences, and those of us who
write Perl using vi/vim struggle daily with the differences. In my own
case, I sometimes spend much more time trying to construct a regular
expression compatible with vi than I would have spent either doing the
edits by hand and then finding and correcting all the inadvertent
errors, or by writing a Perl script that would do the same thing. To
give a real life example, I frequently find myself doing something
like this:
STATEMENT 1 is an SQL query
select $id, $one, $two, $three, $four ... from TABLE with $twenty eq
'twenty';
STATEMENT 2 is a hash assignment
$hash{$id} =3D { one =3D> $one, two =3D> $two, ... };
STATEMENT 3 is an output statement
$row =3D qq("$id","$hash{$id}{one}","$hash{$id}{two}"...\n);
Using vi, I only have to type STATEMENT 1, and can transform that
statement into STATEMENT 2 and STATEMENT 3, and similar statements,
with just one command, and do so instantly and without any errors. It
saves a great deal of time and effort. Proficiency in a programming
language includes mastery of a programming environment, and many
Perlistas use vi/vim as their primary programming environment. If you
are ignorant of vi/vim, I can see how you might perceive my post as
abusive of clpm. I would be very surprised if, knowing vi/vim and
having struggled with vi regexes, you perceive my post as abusive.
You don't need to be so quick to judge.
> Stating that a post is off-topic does not give license to post it
> to non-related newsgroups.
No, but it at least indicates to people that they should not read the
post if off topic posts offend them. In this case, knowing that the
post concerned a vi regex to preserve interior commas, and that you
would be offended by reading a non-Perl question on clpm, you read it
and took offense anyway. This says a lot more about you than it does
about me.
And yes, I'm cross posting this reply to comp.editors, because members
frequently mention Perl there, to give those who don't regularly read
clpm the opportunity to look at this exchange.
CC.
------------------------------
Date: Thu, 15 Dec 2011 11:59:38 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <slrnjekdjr.53g.tadmc@tadbox.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
> On Dec 15, 10:17 am, Tad McClellan <ta...@seesig.invalid> wrote:
>> All abuses of Usenet are offensive.
>
> I did not abuse Usenet.
Making an off-topic post is clearly an abuse, so yes you did.
>> Your abuse here
What abuse was due to me?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Thu, 15 Dec 2011 13:13:36 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <9e809961-1e16-4cfd-aeba-5935f4b2fe35@p16g2000yqd.googlegroups.com>
On Dec 15, 12:59=A0pm, Tad McClellan <ta...@seesig.invalid> wrote:e:
> >> All abuses of Usenet are offensive.
>
> > I did not abuse Usenet.
>
> Making an off-topic post is clearly an abuse, so yes you did.
As I said, proficiency in a programming language requires mastery of
some programming environment. The vi editor has been used over the
years as the programming environment of choice for a number of
different purposes, Perl programming is one, and I personally also use
it for programs that I write in Common Lisp, HTML, LaTeX, SQL, Java,
and I also use it a lot for plain data files.
There is a penumbra (if you will) of topics that fit more or less well
into the interests of those who use Perl. These include both editors
and regular expressions. I asked about both of these. Clearly, if I
had made a post concerning religion, politics, sex, or a multitude of
other things I would have committed an abuse.
I will bet you money that if you asked 1,000 people who use, have
used, or would like to use, Perl, if my topic was legitimate for Perl
users to discuss, anywhere from ten percent to ninety percent would
find the topic agreeable.
And maybe the real test is this: if I had asked the question about a
PERL re rather than a VI re, which I very well could have done, not
even you would have found it abusive in any way. It wasn't the subject
matter of the post that apparently has your panties in a wad, but the
manner of expression.
My question concerned the construction of a regular expression. It's
immaterial whether I wanted to use it in a Perl script, or as an ex
command, or for any other purpose. I don't think regular expressions
are off topic in clpm.
CC.
------------------------------
Date: Thu, 15 Dec 2011 22:58:53 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <dmaqr8-4qk.ln1@anubis.morrow.me.uk>
Quoth ccc31807 <cartercc@gmail.com>:
>
> And maybe the real test is this: if I had asked the question about a
> PERL re rather than a VI re, which I very well could have done, not
> even you would have found it abusive in any way.
No. In that case it would have been on-topic.
> It wasn't the subject
> matter of the post that apparently has your panties in a wad, but the
> manner of expression.
No. It was the subject matter. vi is not Perl; this group is for
discussing Perl (and, occasionally, perl).
> My question concerned the construction of a regular expression. It's
> immaterial whether I wanted to use it in a Perl script, or as an ex
> command, or for any other purpose. I don't think regular expressions
> are off topic in clpm.
Regular expressions *in general* are off-topic here. (Ir-)regular
expressions *as used in Perl* are on topic, though those asking must be
ready for answers of the form 'you shouldn't use a regex for this, you
should <foo> instead' and not be secretly hoping to translate the
regexes they get into a different system.
People asking general regular expression questions here 'because Perl
uses them and there isn't anywhere else to ask' is one of the things
the regulars tend to react particularly badly to, since it happens a lot
more often than it should.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3569
***************************************
