[32981] in Perl-Users-Digest
Perl-Users Digest, Issue: 4257 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 30 03:09:18 2014
Date: Wed, 30 Jul 2014 00:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 30 Jul 2014 Volume: 11 Number: 4257
Today's topics:
Re: Determining the last key when iterating through a h (Tim McDaniel)
Re: Determining the last key when iterating through a h (Tim McDaniel)
Re: Determining the last key when iterating through a h <rweikusat@mobileactivedefense.com>
Re: Determining the last key when iterating through a h <derykus@gmail.com>
Re: Determining the last key when iterating through a h <gravitalsun@hotmail.foo>
Re: Determining the last key when iterating through a h <rweikusat@mobileactivedefense.com>
Re: Determining the last key when iterating through a h <rweikusat@mobileactivedefense.com>
Re: Determining the last key when iterating through a h <rweikusat@mobileactivedefense.com>
Re: Determining the last key when iterating through a h <gravitalsun@hotmail.foo>
Learning english with perl6 <gamo@telecable.es>
Re: Learning english with perl6 <gamo@telecable.es>
Re: Regex to select between first and third occurence o <gamo@telecable.es>
Re: Regex to select between first and third occurence o <news@lawshouse.org>
Re: Regex to select between first and third occurence o <janek_schleicher@yahoo.de>
Re: Regex to select between first and third occurence o <gamo@telecable.es>
Re: Regex to select between first and third occurence o <news@lawshouse.org>
Re: Regex to select between first and third occurence o <gamo@telecable.es>
Re: Regex to select between first and third occurence o <gamo@telecable.es>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 28 Jul 2014 17:15:22 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <lr60fa$mv8$1@reader1.panix.com>
In article <871tt6e2gi.fsf@stemsystems.com>,
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>
> TM> In article <53d3700f$0$2966$e4fe514c@news2.news.xs4all.nl>,
> TM> Dr.Ruud <rvtol+usenet@xs4all.nl> wrote:
> >> On 2014-07-26 02:27, Tim McDaniel wrote:
> >>
> >>> @regular = sort keys %signals;
> >>> $last = pop @regular;
> >>> foreach $item (@regular, $last) {
> >>
> >> If @regular was an empty list, you'll now loop once with undef.
>
> TM> Not true. An empty list is interpolated as ... an empty list.
>
>but $last is undef and will cause the loop to iterate one time.
What are you going on about? The loop works perfectly fine if
@regular is empty.
#! /usr/bin/perl
use strict;
use warnings;
my %signals = (A => 3);
my @regular = sort keys %signals;
my $last = pop @regular;
if (@regular == 0) {
print "regular is empty ...";
}
if (! defined $last) {
print "but last is not undef\n";
}
foreach my $item (@regular, $last) {
print "item is [$item]\n";
}
exit 0;
If you mean that %signals is empty, so @regular STARTS OUT empty, I
will write for the third time that the coder would need to check first
whether %signals is empty and do something appropriate in that case.
>better to do:
>
> $last = $regular[-1] ;
> foreach my $item( @regular ) {
>
>then you will only loop if you have elements and you can still test for
>last.
That *is* a better scheme, not needing a separate "if" to check for
empty %signals, though I dislike deliberate undefs.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 28 Jul 2014 17:19:43 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <lr60nf$mdt$1@reader1.panix.com>
In article <87fvhmven2.fsf@sable.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>But the general idea of a loop like this:
>
>for (@list) {
> # actions supposed to be performed repeatedly
>
> if (test()) {
> # actions supposed to be performed
> # once after all but the last item
> # were processed
> }
>}
>
>is sort-of a travesty as the while concept of 'a loop' is 'perform the
>same operation repeatedly'. Because of this, this should generally rather
>be
>
>for (@list[0 .. $#list - 1]) {
> # actions supposed to be performed repeatedly
>}
># do something special with $list[-1]
Unless, as I posited, the last iteration shares a lot of code with
previous iterations, in which it may be clearer (as in any case of
shared code) to have shared code with "if"s.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 28 Jul 2014 18:29:53 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <87sill1je6.fsf@sable.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <87fvhmven2.fsf@sable.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>>But the general idea of a loop like this:
>>
>>for (@list) {
>> # actions supposed to be performed repeatedly
>>
>> if (test()) {
>> # actions supposed to be performed
>> # once after all but the last item
>> # were processed
>> }
>>}
>>
>>is sort-of a travesty as the while concept of 'a loop' is 'perform the
>>same operation repeatedly'. Because of this, this should generally rather
>>be
>>
>>for (@list[0 .. $#list - 1]) {
>> # actions supposed to be performed repeatedly
>>}
>># do something special with $list[-1]
>
> Unless, as I posited, the last iteration shares a lot of code with
> previous iterations, in which it may be clearer (as in any case of
> shared code) to have shared code with "if"s.
In this case, the next best approach would be to have the shared code in
the loop and the one-shot code behind it. It is also conceivable that
the if in the loop is really the most sensible approach but all of this
depends on unknown circumstances. Insofar this is (easily) possible,
invariant code should appear outside of loops.
------------------------------
Date: Mon, 28 Jul 2014 21:41:14 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <lr78ln$h66$1@speranza.aioe.org>
On 7/27/2014 2:12 PM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 7/27/2014 11:21 AM, Rainer Weikusat wrote:
>>> Charles DeRykus <derykus@gmail.com> writes:
>>>> On 7/21/2014 2:34 PM, John Black wrote:
>>>>> Running through the sorted keys of a hash as follows:
>>>>>
>>>>> foreach $key (sort keys %signals) {
>>>>> ...
>>>>> }
>>>>>
>>>>> I want to do something different inside the loop if I am working on the last key of the
>>>>> foreach. How can I determine when the current $key is the last one? Thanks.
>>>>>
>>>>>
>>>>
>>>> Another possibility with a fairly modern perl version:
>>>>
>>>> my @keys = sort keys %signals;
>>>> while ( my($index,$key) = each(\@keys) ) {
>>>> if ($index == $#keys) { ... }
>>>> }
>>>
>>> That's even worse than the idea of a test which is executed on all
>>> iterations but known to be false except on the last one (semantically,
>>> as it add yet more surreptitious noise to the loop and technically,
>>> because it is also going to be rather slow).
>>>
>>
>> I'm not sure what you're getting at with "surreptitious noise". An index
>> count provided by perl makes more sense to me and is arguably more
>> intuitive and straightforward than providing one on your own.
>
> Except that perl doesn't provide an index count. Sufficiently
> 'new-fangled' version of Perl overload the meaning of 'each' to apply to
> arrays, too, and return an array index and the corresponding value in
> this case. That's something each has never done during the past 20 years
> so it will be seriously counter-intuitive to a lot of people, especially
> considering that the array indices are not stored in an array: Perl is
> not PHP and has two different data types here.
>
> Equivalent code without each could look like this:
>
> my (@keys, $index) = sort(keys(%signals));
> for (@keys) {
> # perform the loop here
>
> if (++$index == @keys) {
> # perform the stuff which doesn't
> # belong ot the loop here
> }
> }
>
> That's less code and it uses a 'standard' foreach-loop for traversing
> the list. Both perform an operation on each iteration in order to
> maintain a running counter and a second operation to check if the
> current element is the last one.
>
> The claim that
>
> my ($index, $key) = each(\@keys)
>
> .
> .
> .
> if ($index == $#keys)
>
> is inherently 'more intuitive' than
>
> for (@keys) {
>
> if (++$index == @keys)
>
> just because it need more than twenty years until someone came up with
> support for the first variant while the second has existed during all of
> this time seems rather bizarre to me.
I believe 'each','values,'keys' for arrays was added due to strong user
support for it. Arguably TIMTOWTDI trumps the downside. And it's more
seamless since it's available for both hashes and arrays. Side perq: you
restrict the scope of the "index" variable to the loop itself.
>
>> As for the contortions needed to avoid all the "iterations known to be
>> false", I believe this is micro-optimizing for dubious gain and,
>
> One of my all time favorite quote is:
>
> A program is a sort of publication. It's meant to be read by
> the programmer, another programmer (perhaps yourself a few days,
> weeks or years later), and lastly a machine. The machine
> doesn't care how pretty the program is - if the program
> compiles, the machine's happy - but people do, and they should.
> http://www.lysator.liu.se/c/pikestyle.html
>
> IOW, "But the computer doesn't care!" is not a good excuse for writing
> stuff into a loop body which isn't really part of the loop.
>
Yes, but sometimes the trouble taken to disentangle a loop "outsider"
may not be worth it. Perhaps someone considers the loop a kind of visual
encapsulation so they want to localize all the action within the loop.
They shout "TIMTOWTDI" and thumb their nose at the "purity" of the loop :)
--
Charles DeRykus
------------------------------
Date: Tue, 29 Jul 2014 11:22:15 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <lr7ljn$2cbg$1@news.ntua.gr>
#!/usr/bin/perl
use strict;
use warnings;
my %hash = (k1=>'v1', k2=>'v2', k3=>'v3');
my $i = 1;
foreach my $key (sort {$a cmp $b} keys %hash)
{
print "last key " if $i++ == scalar keys %hash;
print "$key , $hash{$key}\n"
}
------------------------------
Date: Tue, 29 Jul 2014 12:08:04 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <87bns84e3v.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 7/27/2014 2:12 PM, Rainer Weikusat wrote:
[...]
>> Except that perl doesn't provide an index count. Sufficiently
>> 'new-fangled' version of Perl overload the meaning of 'each' to apply to
>> arrays, too, and return an array index and the corresponding value in
>> this case. That's something each has never done during the past 20 years
>> so it will be seriously counter-intuitive to a lot of people, especially
>> considering that the array indices are not stored in an array: Perl is
>> not PHP and has two different data types here.
>>
>> Equivalent code without each could look like this:
>>
>> my (@keys, $index) = sort(keys(%signals));
>> for (@keys) {
>> # perform the loop here
>>
>> if (++$index == @keys) {
>> # perform the stuff which doesn't
>> # belong ot the loop here
>> }
>> }
>>
>> That's less code and it uses a 'standard' foreach-loop for traversing
>> the list. Both perform an operation on each iteration in order to
>> maintain a running counter and a second operation to check if the
>> current element is the last one.
>>
>> The claim that
>>
>> my ($index, $key) = each(\@keys)
>>
>> .
>> .
>> .
>> if ($index == $#keys)
>>
>> is inherently 'more intuitive' than
>>
>> for (@keys) {
>>
>> if (++$index == @keys)
>>
>> just because it need more than twenty years until someone came up with
>> support for the first variant while the second has existed during all of
>> this time seems rather bizarre to me.
>
> I believe 'each','values,'keys' for arrays was added due to strong
> user support for it.
That fact that they were added obviously implies that some people who
happened to make themselves heard (and happened to be listened to) were
in favour of this. Renaming each to $favorite_football_club or
$popular_semidressed_young_woman might be even more popular.
[...]
>> One of my all time favorite quote is:
>>
>> A program is a sort of publication. It's meant to be read by
>> the programmer, another programmer (perhaps yourself a few days,
>> weeks or years later), and lastly a machine. The machine
>> doesn't care how pretty the program is - if the program
>> compiles, the machine's happy - but people do, and they should.
>> http://www.lysator.liu.se/c/pikestyle.html
>>
>> IOW, "But the computer doesn't care!" is not a good excuse for writing
>> stuff into a loop body which isn't really part of the loop.
>>
>
> Yes, but sometimes the trouble taken to disentangle a loop "outsider"
> may not be worth it.
Not everyone's thoughts naturally run in tangles.
------------------------------
Date: Tue, 29 Jul 2014 12:28:37 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <877g2w4d5m.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> my %hash = (k1=>'v1', k2=>'v2', k3=>'v3');
> my $i = 1;
>
> foreach my $key (sort {$a cmp $b} keys %hash)
> {
> print "last key " if $i++ == scalar keys %hash;
The scalar can be omitted here as the == implies scalar context.
Alternatively, something like
print "last key " if $i++ == scalar abs int (keys(%hash) - 0);
could be used to give the impression of a more elaborate calculation.
Or maybe
print "last key " if ++$i == (scalar(%hash) =~ /(.*)\//)[0] + 1;
print "last key " if ++$i == 1 + %hash;
------------------------------
Date: Tue, 29 Jul 2014 14:14:35 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <87d2coparo.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Charles DeRykus <derykus@gmail.com> writes:
[...]
>> Yes, but sometimes the trouble taken to disentangle a loop "outsider"
>> may not be worth it.
>
> Not everyone's thoughts naturally run in tangles.
I admit that I regret to have written this. A more neutral version could
be: Loops with inlined 'final iteration' special-cases don't exist
naturally and might be 'disentangled' by a conscious, additional (and
thus, wasted) effort, they're consciously create by people which might
as well consciously create something different. Which means there's an
option for discussing the pros and contras of a set of approaches and
chosing one after weighing the arguments for and against it.
------------------------------
Date: Tue, 29 Jul 2014 16:20:06 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <lr872a$in4$1@news.ntua.gr>
Στις 29/7/2014 2:28 μμ, ο/η Rainer Weikusat έγραψε:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>
>> #!/usr/bin/perl
>> use strict;
>> use warnings;
>>
>> my %hash = (k1=>'v1', k2=>'v2', k3=>'v3');
>> my $i = 1;
>>
>> foreach my $key (sort {$a cmp $b} keys %hash)
>> {
>> print "last key " if $i++ == scalar keys %hash;
>
> The scalar can be omitted here as the == implies scalar context.
> Alternatively, something like
>
> print "last key " if $i++ == scalar abs int (keys(%hash) - 0);
>
> could be used to give the impression of a more elaborate calculation.
> Or maybe
>
> print "last key " if ++$i == (scalar(%hash) =~ /(.*)\//)[0] + 1;
>
> print "last key " if ++$i == 1 + %hash;
>
>
: )
------------------------------
Date: Tue, 29 Jul 2014 00:49:05 +0200
From: gamo <gamo@telecable.es>
Subject: Learning english with perl6
Message-Id: <lr6k1l$5ct$1@speranza.aioe.org>
user@host:~/rakudo-star-2014.04$ ./perl6 5x5e.pl
===SORRY!=== Error while compiling 5x5e.pl
Unable to parse quote-words subscript; couldn't find right angle quote
at 5x5e.pl:130
------> <BOL>⏏<EOL>
expecting any of:
postfix
user@host:~/rakudo-star-2014.04$
130 is the number of line which contains EOF
TIA
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Tue, 29 Jul 2014 10:55:22 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Learning english with perl6
Message-Id: <lr7nid$hn5$1@speranza.aioe.org>
El 29/07/14 a las #4, gamo escribió:
>
> user@host:~/rakudo-star-2014.04$ ./perl6 5x5e.pl
> ===SORRY!=== Error while compiling 5x5e.pl
> Unable to parse quote-words subscript; couldn't find right angle quote
> at 5x5e.pl:130
> ------> <BOL>⏏<EOL>
> expecting any of:
> postfix
> user@host:~/rakudo-star-2014.04$
>
> 130 is the number of line which contains EOF
>
> TIA
>
Well, rakudo doesn't like expression without spaces like
if ($i+1<=$L) {}
It makes a difference if you write
if ( $i + 1 <= $L ) {}
Sounds like it needs more maturity.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Mon, 28 Jul 2014 11:36:39 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Regex to select between first and third occurence of comma
Message-Id: <lr55jo$6f4$1@speranza.aioe.org>
El 28/07/14 a las #4, Henry Law escribi:
> On 24/07/14 14:17, IJALAB wrote:
>> I have lot of lines like below:
>>
>> "MONTH", 1, NULL, 0}, //11
>
>>
>> I need the following output:
>>
>>
>> "MONTH", //11
>
> I would use Text::CSV for that; works well, easy to use, and insulates
> you from so many CSV-related things that you don't think of.
>
IMHO neither strings are proper CSV
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Mon, 28 Jul 2014 11:35:54 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Regex to select between first and third occurence of comma
Message-Id: <6fKdnWKc7_oQukvOnZ2dnUVZ8radnZ2d@giganews.com>
On 28/07/14 10:36, gamo wrote:
> IMHO neither strings are proper CSV
I can see that you're right, but nevertheless
#!/usr/bin/perl
use strict;
use warnings;
use Text::CSV;
my $csv = Text::CSV->new ();
while ( my $row = $csv->getline( \*DATA ) ) {
printf("[0]:%s, [4]:%s\n", $row->[0], $row->[4]);
}
__DATA__
"MONTH", 1, NULL, 0}, //11
"YEAR", 1, NULL, 0}, //12
"HOUR", 1, NULL, 0}, //13
"MINUTE", 1, NULL, 0}, //14
"SECOND", 1, NULL, 0}, //15
$ ./tryout
[0]:MONTH, [4]: //11
[0]:YEAR, [4]: //12
[0]:HOUR, [4]: //13
[0]:MINUTE, [4]: //14
[0]:SECOND, [4]: //15
--
Henry Law Manchester, England
------------------------------
Date: Mon, 28 Jul 2014 12:46:45 +0200
From: Janek Schleicher <janek_schleicher@yahoo.de>
Subject: Re: Regex to select between first and third occurence of comma
Message-Id: <c3mnvvFpt7nU1@mid.individual.net>
On 28.07.2014 11:36, gamo wrote:
>>> "MONTH", 1, NULL, 0}, //11
>>
>>>
>>> "MONTH", //11
>>
>> I would use Text::CSV for that; works well, easy to use, and insulates
>> you from so many CSV-related things that you don't think of.
>>
>
>
> IMHO neither strings are proper CSV
Not sure what you mean,
if we follow the RFC 4180 http://tools.ietf.org/html/rfc4180 definition
for CSV files, strings are.
<<'RFC4180
[...]
4. Within the header and each record, there may be one or more
fields, separated by commas. Each line should contain the same
number of fields throughout the file. Spaces are considered part
of a field and should not be ignored. The last field in the
record must not be followed by a comma. For example:
aaa,bbb,ccc
5. Each field may or may not be enclosed in double quotes (however
some programs, such as Microsoft Excel, do not use double quotes
at all). If fields are not enclosed with double quotes, then
double quotes may not appear inside the fields. For example:
"aaa","bbb","ccc" CRLF
zzz,yyy,xxx
6. Fields containing line breaks (CRLF), double quotes, and commas
should be enclosed in double-quotes. For example:
"aaa","b CRLF
bb","ccc" CRLF
zzz,yyy,xxx
7. If double-quotes are used to enclose fields, then a double-quote
appearing inside a field must be escaped by preceding it with
another double quote. For example:
"aaa","b""bb","ccc"
The ABNF grammar [2] appears as follows:
file = [header CRLF] record *(CRLF record) [CRLF]
header = name *(COMMA name)
record = field *(COMMA field)
name = field
field = (escaped / non-escaped)
escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE
non-escaped = *TEXTDATA
COMMA = %x2C
CR = %x0D ;as per section 6.1 of RFC 2234 [2]
[...]
RFC4180
Greetings,
Janek Schleicher
------------------------------
Date: Mon, 28 Jul 2014 13:13:17 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Regex to select between first and third occurence of comma
Message-Id: <lr5b8u$m1d$1@speranza.aioe.org>
El 28/07/14 a las #4, Henry Law escribi:
> On 28/07/14 10:36, gamo wrote:
>> IMHO neither strings are proper CSV
>
> I can see that you're right, but nevertheless
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use Text::CSV;
> my $csv = Text::CSV->new ();
> while ( my $row = $csv->getline( \*DATA ) ) {
> printf("[0]:%s, [4]:%s\n", $row->[0], $row->[4]);
> }
> __DATA__
> "MONTH", 1, NULL, 0}, //11
> "YEAR", 1, NULL, 0}, //12
> "HOUR", 1, NULL, 0}, //13
> "MINUTE", 1, NULL, 0}, //14
> "SECOND", 1, NULL, 0}, //15
>
> $ ./tryout
> [0]:MONTH, [4]: //11
> [0]:YEAR, [4]: //12
> [0]:HOUR, [4]: //13
> [0]:MINUTE, [4]: //14
> [0]:SECOND, [4]: //15
>
Doing this you remove the double quotes from "MONTH"
which I think it's not intended by the OP.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Mon, 28 Jul 2014 12:31:44 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Regex to select between first and third occurence of comma
Message-Id: <WtKdnbKnA8U-qUvOnZ2dnUVZ8l-dnZ2d@giganews.com>
On 28/07/14 12:13, gamo wrote:
> Doing this you remove the double quotes from "MONTH"
> which I think it's not intended by the OP.
Here our discussion founders on whether or not the code being written is
for a specific data set whose format is known in detail and consistent.
If that's the case then the OP can easily replace the double quotes if
required; if not ...
All that I was trying to say in my original article was that unless
you're an absolute whizz with regexes (and I'm sure you are, G) then it
can take longer to hack something together using them than by using some
existing module, and if necessary hacking its output. The main problem,
in my experience, in using regexes is that they can appear to work in
testing, and then some edge case appears in live running in which the
regex /silently/ does something undesirable.
In this particular case it might even be expedient to split on /\s*,\s*/
and fiddle around with the resulting tokens.
--
Henry Law Manchester, England
------------------------------
Date: Mon, 28 Jul 2014 13:35:32 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Regex to select between first and third occurence of comma
Message-Id: <lr5cil$pdi$1@speranza.aioe.org>
El 28/07/14 a las #4, Janek Schleicher escribi:
> 7. If double-quotes are used to enclose fields, then a double-quote
> appearing inside a field must be escaped by preceding it with
> another double quote. For example:
>
> "aaa","b""bb","ccc"
That's the case. IMHO then "MONTH" to be preserved must be
represented as ""MONTH""
...wich after processing will be "MONTH"
Again, not as expected by the OP.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Mon, 28 Jul 2014 13:48:00 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Regex to select between first and third occurence of comma
Message-Id: <lr5da1$r9v$1@speranza.aioe.org>
El 28/07/14 a las #4, Henry Law escribi:
> On 28/07/14 12:13, gamo wrote:
>> Doing this you remove the double quotes from "MONTH"
>> which I think it's not intended by the OP.
>
> Here our discussion founders on whether or not the code being written is
> for a specific data set whose format is known in detail and consistent.
> If that's the case then the OP can easily replace the double quotes if
> required; if not ...
>
> All that I was trying to say in my original article was that unless
> you're an absolute whizz with regexes (and I'm sure you are, G) then it
> can take longer to hack something together using them than by using some
> existing module, and if necessary hacking its output. The main problem,
> in my experience, in using regexes is that they can appear to work in
> testing, and then some edge case appears in live running in which the
> regex /silently/ does something undesirable.
>
> In this particular case it might even be expedient to split on /\s*,\s*/
> and fiddle around with the resulting tokens.
>
Well, I we could "improve" the OP request, then I bet by the Jrgen
Exner solution: not to use regex at all.
He wrote:
|No need for a RE, this can more easily be done with a simple split:
| $_ = '"MONTH", 1, NULL, 0}, //11';
| print join ',', (split ',', $_)[0,-1];
--
http://www.telecable.es/personales/gamo/
------------------------------
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 4257
***************************************
