[32303] in Perl-Users-Digest
Perl-Users Digest, Issue: 3570 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Dec 16 16:09:49 2011
Date: Fri, 16 Dec 2011 13:09:09 -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 Fri, 16 Dec 2011 Volume: 11 Number: 3570
Today's topics:
Re: CGI alternatives/replacements <rweikusat@mssgmbh.com>
Re: CGI alternatives/replacements <tzz@lifelogs.com>
Re: Problem configuring OS/2 for installing CPAN packag <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 <tzz@lifelogs.com>
Re: Use of uninitialized value: when don't you get that <lcof@nospam.invalid>
Re: Use of uninitialized value: when don't you get that <lcof@nospam.invalid>
Re: Use of uninitialized value: when don't you get that <lcof@nospam.invalid>
Re: Use of uninitialized value: when don't you get that (Tim McDaniel)
Re: Use of uninitialized value: when don't you get that (Tim McDaniel)
Re: Use of uninitialized value: when don't you get that <rweikusat@mssgmbh.com>
Re: Use of uninitialized value: when don't you get that <tadmc@seesig.invalid>
Re: vi regex to preserve interior commas in CSV string <ben@morrow.me.uk>
Re: vi regex to preserve interior commas in CSV string <kkeller-usenet@wombat.san-francisco.ca.us>
Re: vi regex to preserve interior commas in CSV string <jurgenex@hotmail.com>
Re: vi regex to preserve interior commas in CSV string <jurgenex@hotmail.com>
Re: vi regex to preserve interior commas in CSV string <jurgenex@hotmail.com>
Re: vi regex to preserve interior commas in CSV string <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 16 Dec 2011 00:02:07 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <878vmd75a8.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> 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
[...]
> Other people may use other solutions:
[...]
> Any of these solutions is, IMHO, better than putting
> HTML-generating code in with your main program logic.
Provided the HTML-generating code is sufficiently complicated enough
that moving it out of focus actually buys something and is not just an
encumbrance, it can always be moved to a different file without also
moving it to a different language. And with a relatively tiny amount
of abstraction, 'HTML-generating code' can easily look like this:
sub form()
{
return ($cgi->start_form(-action => 'vmecs-create.cgi'),
$cgi->table(7, #{ border => 1 },
$cgi->t_r(menu('company')),
$cgi->empty_line(),
two_params(['name', 20, MAX_DNS_LABEL],
['dns_domain', 40, MAX_DNS_NAME]),
$cgi->empty_line(),
two_params(['ipv4_addr', MAX_DOTTED_QUAD],
['netmask', MAX_DOTTED_QUAD]),
$cgi->flush_right(3,
param('gate', MAX_DOTTED_QUAD)),
$cgi->empty_line(),
two_params(['pool_net', MAX_DOTTED_QUAD],
['pool_mask', MAX_DOTTED_QUAD]),
$cgi->flush_right(3,
param('pool_size', MAX_U32)),
$cgi->empty_line(),
$cgi->flush_right(3,
param('mac_addr', MAC_LEN)),
$cgi->flush_right(3,
$cgi->expln(Lng::str('vmecs_optional'))),
$cgi->empty_line(),
$cgi->flush_right(3,
$cgi->titled_cell(Lng::str('vmecs_start_now'),
checkbox('start'))),
$cgi->empty_line(),
buttons()),
$cgi->end_form(), "\n");
}
[(c) my employer, quoted for educational purposes]
(no, I don't care for the random W3C standard of the day)
[...]
> 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.
Funny as it may seem, this 'extremely inefficient solution' (meaning,
doing a fork-and-exec per invocation) was efficient enough for being
used on hardware which was much feebler than what is used for a
present-day smartphones. This implies that it really ought to be much
more widely applicable than it was fifteen years ago. The amount of
code which needs to be compiled being orders of magnitude larger
than the amount of code which is actually used would be a design
problem. And there is nothing 'modern' in the "I'll what I can
download for free on the internet and glue that together somehow,
technically sensible soluting be damned, I can't program!" approach to
solving a problem: That's what some people have been doing ever since
the option became available. In a different context, there's a German
verb for this activity, namely 'abschreiben' (I would wager a bet that
the sets of people clinging to either 'problem solving methodology'
are more or less identical).
------------------------------
Date: Fri, 16 Dec 2011 10:41:25 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <87mxaso4ei.fsf@lifelogs.com>
On Thu, 15 Dec 2011 22:48:53 +0000 Ben Morrow <ben@morrow.me.uk> wrote:
BM> My understanding is that this is exactly what 'lighter' frameworks like
BM> Mojo and Dancer are supposed to address: getting to 'hello world' is
BM> meant to be much quicker. I rather suspect that on a project of any size
BM> the complexity has to go somewhere, and it just ends up finding its way
BM> in later, but I've never used them in anger so I don't know.
I've been very happy and productive lately using CouchDB and couch apps
to host all the content without any CGI interactions. For a certain
application domain, it's a very nice lightweight approach and the
built-in replication doesn't hurt. Plus Perl plays very nicely with
JSON content and there are plenty of modules for CouchDB interaction
(AnyEvent::CouchDB is my favorite).
In the Perl world, I really like Dancer and Mojolicious. Simple things
made simple.
Ted
------------------------------
Date: Thu, 15 Dec 2011 23:05:11 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <72bqr8-4qk.ln1@anubis.morrow.me.uk>
[OS/2 groups removed from Newsgroups: they don't need Unix advocacy...]
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> 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.
Well, on a Real System poll(2) is a syscall, so its behaviour is
governed by the kernel. And in any case, libc is part of the OS, or
ought to be.
> I would not be surprised if this test passes on OS/2 + EMX.
I am beginning to seriously get the impression the OP would be much
better off starting with (real) EMX and the 5.14.4 tarball and building
a normal perl with -Dprefix=q:/programs/perl. Do you happen to know if
that is an easy thing to do?
Ben
------------------------------
Date: Fri, 16 Dec 2011 19:42:21 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Problem configuring OS/2 for installing CPAN packages
Message-Id: <slrnjen7ot.tvr.nospam-abuse@panda.math.berkeley.edu>
On 2011-12-15, Ben Morrow <ben@morrow.me.uk> wrote:
>> Such things are properties of CRT libraries, not OSes.
> Well, on a Real System poll(2) is a syscall,
[OT] You mean "OSes initially designed to be one-process one-user [*],
and intially designed by a bunch of kids who intentionally threw away
all the clues about problems in OS design and their possible
solutions, the clues gathered in previous 20 years"? :-(
[*] Well, processes COULD be started in parallel, but without any
real IPC mechanism: you know, the "640K and pipeline +
command-line + environment should be enough for everybody"
mentality.
[*] Likewise, several users could be defined for the system, but
essentially they should have been the same person in different
hats. E.g., the system admin has MORE privileges than a normal
user (an inversion of how it should be in real life if they are
different people...).
I sometimes wonder what the CS world would be now if Multics had no
viable competitor for other 5 years, when due to Moor's law it had
better chance to gain mini-computer ground...
> so its behaviour is
> governed by the kernel. And in any case, libc is part of the OS, or
> ought to be.
Well, it is not on most systems Perl is used nowadays, so why dream?
>> I would not be surprised if this test passes on OS/2 + EMX.
>
> I am beginning to seriously get the impression the OP would be much
> better off starting with (real) EMX and the 5.14.4 tarball and building
> a normal perl with -Dprefix=q:/programs/perl. Do you happen to know if
> that is an easy thing to do?
I did not try...
Ilya
------------------------------
Date: Fri, 16 Dec 2011 10:36:13 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Question on using perl in a cgi script
Message-Id: <87r504o4n6.fsf@lifelogs.com>
On Thu, 15 Dec 2011 09:54:56 -0800 (PST) ccc31807 <cartercc@gmail.com> wrote:
c> On Dec 15, 10:21 am, Tad McClellan <ta...@seesig.invalid> wrote:
>> The else clause is unreachable, so it should not be there.
c> Yeah, and I also left out the
c> print "Content-type: text/html\n\n";
c> line as well. So, just regard it as what I said it was, a hypothetical
c> script written in Perlish pseudocode.
But that's not useful.
Please try to post complete working examples. This one was nearly so
which is much more confusing than actual pseudocode.
Ted
------------------------------
Date: Fri, 16 Dec 2011 08:47:28 +0000 (UTC)
From: Lucien Coffe <lcof@nospam.invalid>
Subject: Re: Use of uninitialized value: when don't you get that?
Message-Id: <jcf0j0$7e7$1@speranza.aioe.org>
Tim McDaniel wrote :
> I like to have "use strict" and "use warnings" (actually, "-w" on my
> scripts).
I think the "use warnings" way is the recommended way. It is scoped to
the file/package, and is clearer.
> 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.
Put it that way : *undef* can be true or false; In list context it is
true, in all scalar contexts it is false. So testing it is not a problem.
#!/usr/bin/perl
use strict;
use warnings;
use diagnostics;
my $x = undef;
print 1,"\n" if( [ $x ] ); # true
print 2,"\n" if( $x ); # false
print 3,"\n" if( $x++ ); # false
$x = undef;
print 4,"\n" if( ++$x ); # true
$x = undef;
print 5,"\n" if ref $x; # false
print 6,"\n" if( $x->{foo} ); # true
print 7,"\n" if ref $x; # now true, ref $x = HASH
$x = undef;
print 8,"\n" if( "$x" ); # w uninitialized
print 9,"\n" if( $x == 1 ); # w uninitialized
Output from the diagnostics pragma :
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.
So if you use undef explicitly as a string or as a numeric value, you get
the warning. Hope this helps.
------------------------------
Date: Fri, 16 Dec 2011 08:54:18 +0000 (UTC)
From: Lucien Coffe <lcof@nospam.invalid>
Subject: Re: Use of uninitialized value: when don't you get that?
Message-Id: <jcf0vq$8pj$1@speranza.aioe.org>
Lucien Coffe wrote :
> So if you use undef explicitly as a string or as a numeric value, you
> get the warning.
* If you use it explicitly as a string, or if you compare it as a
numerical value.
> Hope this helps.
------------------------------
Date: Fri, 16 Dec 2011 09:11:26 +0000 (UTC)
From: Lucien Coffe <lcof@nospam.invalid>
Subject: Re: Use of uninitialized value: when don't you get that?
Message-Id: <jcf1vu$aqc$1@speranza.aioe.org>
Lucien Coffe wrote :
> Lucien Coffe wrote :
>
>> So if you use undef explicitly as a string or as a numeric value, you
>> get the warning.
>
> * If you use it explicitly as a string, or if you compare it as a
> numerical value.
>
>> Hope this helps.
Bumping again.
$x = undef;
print 10,"\n" if( $x+1 ); # w uninitialized
undef++ is undef, ++undef is 1, undef+1 triggers the warning because you
try to interpret undef to it's numerical value to use the + operator.
Someone correct me if I'm wrong.
------------------------------
Date: Fri, 16 Dec 2011 16:17:04 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Use of uninitialized value: when don't you get that?
Message-Id: <jcfqu0$j1i$1@reader1.panix.com>
In article <jcf0j0$7e7$1@speranza.aioe.org>,
Lucien Coffe <lcof@nospam.invalid> wrote:
>Tim McDaniel wrote :
>
>> I like to have "use strict" and "use warnings" (actually, "-w" on
>> my scripts).
>
>I think the "use warnings" way is the recommended way. It is scoped
>to the file/package, and is clearer.
Quite so, quite so. I was thinking of the scripts that I've done for
myself, where there's just one file and I'm invoking it as a command.
(I started with Perl 4.036, I think: I'm pretty sure "use warnings"
didn't exist; I don't remember whether "my" even existed, and I
suspect not.)
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 16 Dec 2011 16:44:30 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Use of uninitialized value: when don't you get that?
Message-Id: <jcfshd$qa7$1@reader1.panix.com>
In article <jcf0j0$7e7$1@speranza.aioe.org>,
Lucien Coffe <lcof@nospam.invalid> wrote:
>Put it that way : *undef* can be true or false; In list context it is
>true, in all scalar contexts it is false.
As I understand it, a boolean context is not a list context, and if
you use undef in a list context, it's put into a list of one element,
which evaluates as true regardless of what that element is.
My understanding is that there is really no undef in a list context:
if you use it in a list context, it is put into a list of one element,
and a list of one element evaluates as true in a boolean context
regardless of what that element is.
>my $x = undef;
>print 1,"\n" if( [ $x ] ); # true
That's testing [...], not undef or lists.
print 1.1,"\n" if( [ ] );
prints 1.1. [...] generates a reference to a list, and a reference to
a list evaluates as true regardless of what the elements are or even,
apparently, whether there are even any elements.
>print 6,"\n" if( $x->{foo} ); # true
False in 5.014002 on NetBSD, 5.008008 on something, and I would be
astonished if it were true anywhere.
>print 7,"\n" if ref $x; # now true, ref $x = HASH
That's true.
Looking further at "man perldiag":
Use of uninitialized value%s
(W uninitialized) An undefined value was used as if it were
already defined. It was interpreted as a "" or a 0, but maybe it
was a mistake. ...
I'm thinking that the first sentence is somewhat imprecise or unclear.
I think the second sentence is the condition: "Use of uninitialized
value" occurs if and only if you use an undef value with an operator
that requires numeric operands (like +, *, ==) or string operands
(like ., printf "%s", split), and not otherwise.
But I'd like to hear from someone authoritative, like someone who
knows how to navigate the source for "perl".
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 16 Dec 2011 18:01:57 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Use of uninitialized value: when don't you get that?
Message-Id: <87wr9wxune.fsf@sapphire.mobileactivedefense.com>
Lucien Coffe <lcof@nospam.invalid> writes:
[...]
> Put it that way : *undef* can be true or false; In list context it is
> true, in all scalar contexts it is false.
This is wrong. Invoking a subroutine returning undef in list context
effectivelty causes that to return a list containing a single element
whose value is 'the undefined value'. If this list is assigned to an
array and the array then evaluated in scalar context, the result will
be the number 1 which is regarded as true:
[rw@sapphire]~ $perl -de 0
Loading DB routines from perl5db.pl version 1.32
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:1): 0
DB<1> sub axtmoerder { return undef; }
DB<2> @a = axtmoerder
DB<3> p scalar(@a)
1
DB<4> p $a[0] || 3
3
[...]
> Output from the diagnostics pragma :
>
> (W uninitialized) An undefined value was used as if it were already
> defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
> To suppress this warning assign a defined value to your variables.
I really think 'we' need another warning whose diagnostics output
should roughly be like this:
An addition operator was used. This was interpreted as an
addition but maybe it was a mistake. To suppress this warning,
add the comment # I mean it !!1 to the corresponding line of
the code.
------------------------------
Date: Fri, 16 Dec 2011 12:16:59 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Use of uninitialized value: when don't you get that?
Message-Id: <slrnjen30k.95q.tadmc@tadbox.sbcglobal.net>
Tim McDaniel <tmcd@panix.com> wrote:
> (I started with Perl 4.036, I think: I'm pretty sure "use warnings"
> didn't exist; I don't remember whether "my" even existed, and I
> suspect not.)
Perl 4 did not have lexical variables (my) nor a "use" statement
at all, let alone that particular pragma.
--
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 23:22:24 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <g2cqr8-4qk.ln1@anubis.morrow.me.uk>
[Followup-To ignored]
Quoth ccc31807 <cartercc@gmail.com>:
> On Dec 15, 10:17 am, Tad McClellan <ta...@seesig.invalid> wrote:
> > All abuses of Usenet are offensive.
>
> I did not abuse Usenet.
I, perhaps, wouldn't go so far as 'abuse'; but your post was definitely
off-topic, which is definitely rude.
> > Your abuse here displays a rather profound selfishness on your part.
>
> Actually, your abuse displays a rather profound selfishness on your
> part.
I fail to see how anything Tad has said could reasonably be described as
'selfish'. One could perhaps accuse both me and him of being a little
officious, but we believe that is an unfortunate necessity on Usenet.
> Proficiency in a programming
> language includes mastery of a programming environment, and many
> Perlistas use vi/vim as their primary programming environment.
'In order to learn Perl one must eat; therefore cookery is on-topic in
clpmisc.'
> 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.
I am writing this post in Vim. As you may have gathered, I found your
post off-topic.
> And yes, I'm cross posting this reply to comp.editors,
[you aren't, actually: Followup-To ne Newsgroups]
> because members
> frequently mention Perl there, to give those who don't regularly read
> clpm the opportunity to look at this exchange.
So you're spamming two groups instead of just one? How considerate of
you.
Ben
------------------------------
Date: Thu, 15 Dec 2011 15:42:53 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <t8dqr8xqv4.ln2@goaway.wombat.san-francisco.ca.us>
On 2011-12-15, Ben Morrow <ben@morrow.me.uk> wrote:
> [Followup-To ignored]
>
> Quoth ccc31807 <cartercc@gmail.com>:
>> On Dec 15, 10:17?am, Tad McClellan <ta...@seesig.invalid> wrote:
>> > All abuses of Usenet are offensive.
>>
>> I did not abuse Usenet.
>
> I, perhaps, wouldn't go so far as 'abuse'; but your post was definitely
> off-topic, which is definitely rude.
This OP has had the same bad posting habits for many years; I am
surprised that people still respond to anything he posts beyond
corrections of blatant untruths.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Thu, 15 Dec 2011 17:40:17 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <i38le71rkuskd6iqdc85gjt3l14giq7t6e@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth ccc31807 <cartercc@gmail.com>:
>>
>> I have discovered that vi will do a lot of what I write little Perl
>> scripts to do, such as convert the output of Excel to a format that I
>> can use. I'm just not that good (yet) with vi regexes.
>
>How entirely fascinating.
>
>What was your Perl question?
Oh, come on! For the first time in his life he discovered a feature that
distinguishes a real editor from a toy and you chastise him?
Cut the guy some slack, at some point we were young and inexperienced,
too.
Of course, the Perl script will do the same thing again and again and
again automatically while for vi or any other editor you either have to
retype the maybe very complex substitute command or save it as a macro
if you ever want to use it again.
jue
------------------------------
Date: Thu, 15 Dec 2011 17:44:17 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <oe8le79ruouep5ek0p7bqleq4aecfepdns@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>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.
And even worse: Perl regular expressions are quite different from e.g.
vi or emacs or .Net or pickYourFavourite regular expressions. Therefore
asking about Perl REs and hoping to be able to use the Perl solution in
a different system is quite naive.
jue
------------------------------
Date: Thu, 15 Dec 2011 17:47:41 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <9l8le7hsu6fi1ch25mo7cfa83efralkq4t@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>[Followup-To ignored]
>
>Quoth ccc31807 <cartercc@gmail.com>:
>> 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.
How is vi special wrt. REs? REs are supported in any standard editor.
No, not in Notepad, but that doesn't qualify as an editor in the first
place.
jue
------------------------------
Date: Thu, 15 Dec 2011 21:10:04 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <slrnjelds0.6ip.tadmc@tadbox.sbcglobal.net>
Jürgen Exner <jurgenex@hotmail.com> wrote:
> at some point we were young and inexperienced,
> too.
But this OP is neither of those.
Just ask him!
--
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: 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 3570
***************************************
