Confused regex parsing of lists #6993

p5pRT · 2003-12-18T17:36:30Z

Migrated from rt.perl.org#24689 (status was 'open')

Searchable as RT24689$

p5pRT · 2003-08-15T12:06:11Z

From @Abigail

Created by @Abigail

$ perl -wle '($a, $b) =~ (0, 0)'
Too many arguments for regexp internal reset at -e line 1, at EOF

This message is confusing because perldiag doesn't mention
'internal reset'. In fact, I don't think an 'internal reset'
is documented anywhere in the documentation.

Perldiag lists it under:

=item Too many arguments for %s

(F) The function requires fewer arguments than you specified.

which is a generic entry, with an explaination that doesn't add
much value.

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.0:

Configured by camel at Mon Oct 28 01:28:45 CET 2002.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.18-bf2.4, archname=i686-linux-64int-ld
    uname='linux alexandra 2.4.18-bf2.4 #1 son apr 14 09:53:28 cest 2002 i686 unknown '
    config_args='-des -Uversiononly -Dmydomain=.abigail.nl -Dcf_email=camel@abigail.nl -Dperladmin=camel@abigail.nl -Doptimize=-g -Dusemorebits -Dusedevel -Dusenm=false -Dprefix=/opt/perl -Dcc=gcc'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=define
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-g',
    cppflags='-DDEBUGGING -fno-strict-aliasing'
    ccversion='', gccversion='3.0.4', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lc -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.0:
    /home/abigail/Perl
    /opt/perl/lib/5.8.0/i686-linux-64int-ld
    /opt/perl/lib/5.8.0
    /opt/perl/lib/site_perl/5.8.0/i686-linux-64int-ld
    /opt/perl/lib/site_perl/5.8.0
    /opt/perl/lib/site_perl
    .


Environment for perl v5.8.0:
    HOME=/home/abigail
    LANG=C
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/home/abigail/Lib:/usr/local/lib:/usr/lib:/lib:/usr/X11R6/lib
    LOGDIR (unset)
    PATH=/home/abigail/Bin:/opt/perl/bin:/usr/local/bin:/usr/local/X11/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/games:/usr/share/texmf/bin:/opt/Acrobat/bin:/opt/java/blackdown/j2sdk1.3.1/bin:/usr/local/games/bin
    PERL5LIB=/home/abigail/Perl
    PERLDIR=/opt/perl
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2003-08-16T20:27:12Z

From enache@rdslink.ro

On Fri, Aug 15, 2003 a.d., abigail@abigail.nl (via RT) wrote:

[Please enter your report here]
$ perl \-wle '$$a\, $b$ =~ $0\, 0$'
Too many arguments for regexp internal reset at \-e line 1\, at EOF
This message is confusing because perldiag doesn't mention
'internal reset'. In fact, I don't think an 'internal reset'
is documented anywhere in the documentation.

'internal reset' is an OP (Perl_pp_regcreset, look at opcode.pl:492).

IMHO, even 'Too many arguments for regcreset' would be less confusing.

Regards,
Adi

p5pRT · 2003-08-16T20:36:00Z

From @rgs

Enache Adrian wrote:

On Fri, Aug 15, 2003 a.d., abigail@abigail.nl (via RT) wrote:
[Please enter your report here]
$ perl \-wle '$$a\, $b$ =~ $0\, 0$'
Too many arguments for regexp internal reset at \-e line 1\, at EOF
This message is confusing because perldiag doesn't mention
'internal reset'. In fact, I don't think an 'internal reset'
is documented anywhere in the documentation.
'internal reset' is an OP (Perl_pp_regcreset, look at opcode.pl:492).

IMHO, even 'Too many arguments for regcreset' would be less confusing.

Yes ; but on the other hand, why does this code produce a syntax error ?
It looks like a perfectly valid (although contrived) line of perl code
to me.

p5pRT · 2003-08-17T14:29:20Z

From enache@rdslink.ro

On Sat, Aug 16, 2003 a.d., Rafael Garcia-Suarez wrote:

$ perl \-wle '\($a\, $b\) =~ \(0\, 0\)'
Too many arguments for regexp internal reset at \-e line 1\, at EOF

...

Yes ; but on the other hand, why does this code produce a syntax error ?
It looks like a perfectly valid (although contrived) line of perl code
to me.

Because Perl_ck_fun <censored> :-)
For ~ the same reason this won't work:

push /^-/ ? @opts : @args, $_;

Regard,
Adi

p5pRT · 2003-12-18T17:36:38Z

From perl-5.8.0@ton.iguana.be

Created by perl-5.8.0@ton.iguana.be

Either me or perl is hopelessly confused here:

perl -cwle 's!.!""=~((),$&)!eg'
Too many arguments for regexp internal reset at -e line 1, near ") }"
-e had compilation errors.

The Deparse looks rather unexpected too:

BEGIN { $^W = 1; }
BEGIN { $/ = "\n"; $\ = "\n"; }
s/./do {
'' =~ (), $&;
};/eg;

(the $& doesn't go with the regex bind anymore)

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.0:

Configured by ton at Tue Nov 12 01:56:18 CET 2002.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.19, archname=i686-linux-thread-multi-64int-ld
    uname='linux quasar 2.4.19 #5 wed oct 2 02:34:25 cest 2002 i686 unknown '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=define
    usemymalloc=y, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -fomit-frame-pointer',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='long double', nvsize=12, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -ldb -ldl -lm -lpthread -lc -lposix -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lpthread -lc -lposix -lcrypt -lutil
    libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.4'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.0:
    /usr/lib/perl5/5.8.0/i686-linux-thread-multi-64int-ld
    /usr/lib/perl5/5.8.0
    /usr/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi-64int-ld
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl
    .


Environment for perl v5.8.0:
    HOME=/home/ton
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/ton/bin.Linux:/home/ton/bin:/home/ton/bin.SampleSetup:/usr/local/bin:/usr/local/sbin:/usr/local/jre/bin:/home/oracle/product/9.0.1/bin:/usr/local/ar/bin:/usr/games/bin:/usr/X11R6/bin:/usr/share/bin:/usr/bin:/usr/sbin:/bin:/sbin:.
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2003-12-20T19:18:35Z

From enache@rdslink.ro

On Sat, Dec 20, 2003 a.d., Ton Hospel wrote:

It makes me sometimes pretty unmotivated to report bugs though. Even if the
bug doesn't get solved, an "ack, that's a bug" would be nice. I currently
have 23 bugreports pending that have never even been acknowledged, so

Your recent [perl #24689] is the same as [perl 23328].
Perl_ck_fun() is deficient - I posted there a similar example with 'push':

push /yes/ ? @yes : @no, $_;

As nobody was enthousiastic about having that fixed, I forgot about it :-)

You have also some reports about regexp blowing the stack. Notice that simply
increasing the limits won't always work: the dynamic loader may mmap
memory chunks in the stack's way -- at reasonable distance from the stack's
lower limit in the address space - but Perl is sooo stack-greedy that it
manages to eat up all that (ex. [perl 23666])

I'll go there for reducing somehow the overhead of the regex functions -
but Hugo van den Sanden promised to come with a definitive solution for that,
so ..

Regards,
Adi

p5pRT · 2003-12-20T19:33:41Z

From enache@rdslink.ro

On Sat, Dec 20, 2003 a.d., I wrote:

but Hugo van den Sanden promised to come with a definitive solution for that,
^^^
Sorry for the typo.

p5pRT · 2003-12-20T19:47:59Z

From perl5-porters@ton.iguana.be

In article <20031220190203.GA1264@ratsnest.hole>,
Enache Adrian <enache@rdslink.ro> writes:

On Sat, Dec 20, 2003 a.d., Ton Hospel wrote:

It makes me sometimes pretty unmotivated to report bugs though. Even if the
bug doesn't get solved, an "ack, that's a bug" would be nice. I currently
have 23 bugreports pending that have never even been acknowledged, so

Your recent [perl #24689] is the same as [perl 23328].

Ah indeed.

Perl_ck_fun() is deficient - I posted there a similar example with 'push':

push /yes/ ? @yes : @no, $_;

Mm, but a distributed push like that is currently invalid perl syntax,
isn't it (though I've met it in practise when classifying a list and
was disapointed it doesn't just work)

As nobody was enthousiastic about having that fixed, I forgot about it :-)

You have also some reports about regexp blowing the stack. Notice that simply
increasing the limits won't always work: the dynamic loader may mmap
memory chunks in the stack's way -- at reasonable distance from the stack's
lower limit in the address space - but Perl is sooo stack-greedy that it
manages to eat up all that (ex. [perl 23666])

Must be incredibly greedy then, since I can blow it up with what a naive
look at the regex looks like a need for only a few thousand recursion levels,
and my default stack is 8 Meg. Seems to need about 2K/level.

Notice also #22095 where i get a "expected" stack coredump since I suppose
the cleanup is recursive. However, again with my stack and lowering the
size until it goes away, it indicates that each level again uses about 2k.
And this is not regex related at all. Coincidence ?
(ps, this bugreport WAS responded to, why is it still in new, it should
be open with maybe a modified header saying "that it can't handle
arbitrary long lists is normal, but the limit seems too low")

Is there maybe some huge automatic variable that gets allocated at each
level or something like that ?

I'll go there for reducing somehow the overhead of the regex functions -
but Hugo van den Sanden promised to come with a definitive solution for that,
so ..

Regards,
Adi

p5pRT · 2010-05-18T21:07:44Z

From @chorny

Same cryptic error on 5.12.0.

On Fri Aug 15 05:06:11 2003, abigail@abigail.nl wrote:

$ perl \-wle '$$a\, $b$ =~ $0\, 0$'
Too many arguments for regexp internal reset at \-e line 1\, at EOF
This message is confusing because perldiag doesn't mention
'internal reset'. In fact, I don't think an 'internal reset'
is documented anywhere in the documentation.

Perldiag lists it under:
=item Too many arguments for %s

$F$ The function requires fewer arguments than you specified\.
which is a generic entry, with an explaination that doesn't add
much value.

Discussion here: http://rt.perl.org/rt3/Ticket/Display.html?id=24689

--
Alexandr Ciornii, http://chorny.net

p5pRT · 2010-05-18T21:07:44Z

From [Unknown Contact. See original ticket]

Same cryptic error on 5.12.0.

On Fri Aug 15 05:06:11 2003, abigail@abigail.nl wrote:

$ perl \-wle '$$a\, $b$ =~ $0\, 0$'
Too many arguments for regexp internal reset at \-e line 1\, at EOF
This message is confusing because perldiag doesn't mention
'internal reset'. In fact, I don't think an 'internal reset'
is documented anywhere in the documentation.

Perldiag lists it under:
=item Too many arguments for %s

$F$ The function requires fewer arguments than you specified\.
which is a generic entry, with an explaination that doesn't add
much value.

Discussion here: http://rt.perl.org/rt3/Ticket/Display.html?id=24689

--
Alexandr Ciornii, http://chorny.net

p5pRT · 2013-01-26T17:42:28Z

From @khwilliamson

On Tue May 18 14:07:44 2010, chorny wrote:

Same cryptic error on 5.12.0.

On Fri Aug 15 05:06:11 2003, abigail@abigail.nl wrote:
$ perl \-wle '$$a\, $b$ =~ $0\, 0$'
Too many arguments for regexp internal reset at \-e line 1\, at EOF
This message is confusing because perldiag doesn't mention
'internal reset'. In fact, I don't think an 'internal reset'
is documented anywhere in the documentation.

Perldiag lists it under:
=item Too many arguments for %s

$F$ The function requires fewer arguments than you specified\.
which is a generic entry, with an explaination that doesn't add
much value.
Discussion here: http://rt.perl.org/rt3/Ticket/Display.html?id=24689

These no longer generate these error messages. Is there any reason to
keep this ticket open?

--
Karl Williamson

p5pRT · 2013-01-26T18:13:20Z

From @nwc10

On Sat, Jan 26, 2013 at 09:42:28AM -0800, Karl Williamson via RT wrote:

On Tue May 18 14:07:44 2010, chorny wrote:
Same cryptic error on 5.12.0.

On Fri Aug 15 05:06:11 2003, abigail@abigail.nl wrote:
$ perl \-wle '$$a\, $b$ =~ $0\, 0$'
Too many arguments for regexp internal reset at \-e line 1\, at EOF

These no longer generate these error messages. Is there any reason to
keep this ticket open?

A bisect shows that it was fixed by this commit:

commit 74529a4
Author: David Mitchell <davem@iabyn.com>
Date: Fri Aug 19 12:10:01 2011 +0100

add Perl_re_op_compile function

Make Perl_re_compile() a thin wrapper around a new function,
Perl_re_op_compile(). This function can take either a string pattern or a
list of ops. Then make pmruntime() pass a list of ops directly to it, rather
concatenating all the consts into a single string and passing the const to
Perl_re_compile(). For now, Perl_re_op_compile just does the same: if its
passed an op tree rather than an SV, then it just concats the consts.

So this is is just the next step towards eventually allowing the regex
engine to use the ops directly.

1) It's not clear *why* this fixes it
2) There seem to be no tests for it

It would be nice to resolve both before closing.

(more generally, it makes me wonder how many long standing open tickets have
no TODO tests)

Nicholas Clark

p5pRT · 2013-01-26T19:34:34Z

From @jkeenan

On Sat Jan 26 09:42:28 2013, khw wrote:

On Tue May 18 14:07:44 2010, chorny wrote:
Same cryptic error on 5.12.0.

On Fri Aug 15 05:06:11 2003, abigail@abigail.nl wrote:
$ perl \-wle '$$a\, $b$ =~ $0\, 0$'
Too many arguments for regexp internal reset at \-e line 1\, at EOF
This message is confusing because perldiag doesn't mention
'internal reset'. In fact, I don't think an 'internal reset'
is documented anywhere in the documentation.

Perldiag lists it under:
=item Too many arguments for %s

$F$ The function requires fewer arguments than you specified\.
which is a generic entry, with an explaination that doesn't add
much value.
Discussion here: http://rt.perl.org/rt3/Ticket/Display.html?id=24689
These no longer generate these error messages. Is there any reason to
keep this ticket open?

I'm a bit puzzled. With Perl 5.16.0, I get:

#####
$ perl -wle '($a, $b) =~ (0, 0)'
Too many arguments for regexp internal reset at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
#####

... on both Darwin/PPC and Linux/i386.

With blead (This is perl 5, version 17, subversion 9 (v5.17.9
(v5.17.8-47-ga951350)) built for darwin-2level), I get:

#####
$ ./perl -wle '($a, $b) =~ (0, 0)'
Useless use of a variable in void context at -e line 1.
Name "main::b" used only once: possible typo at -e line 1.
Name "main::a" used only once: possible typo at -e line 1.
Use of uninitialized value $b in pattern match (m//) at -e line 1.
#####

Does the presence of these latter, more familiar, warnings mean that the
original problem is fixed?

Thank you very much.
Jim Keenan

p5pRT · 2013-01-26T19:39:33Z

From @nwc10

On Sat, Jan 26, 2013 at 11:34:34AM -0800, James E Keenan via RT wrote:

I'm a bit puzzled. With Perl 5.16.0, I get:

#####
$ perl -wle '($a, $b) =~ (0, 0)'
Too many arguments for regexp internal reset at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
#####

... on both Darwin/PPC and Linux/i386.

With blead (This is perl 5, version 17, subversion 9 (v5.17.9
(v5.17.8-47-ga951350)) built for darwin-2level), I get:

#####
$ ./perl -wle '($a, $b) =~ (0, 0)'
Useless use of a variable in void context at -e line 1.
Name "main::b" used only once: possible typo at -e line 1.
Name "main::a" used only once: possible typo at -e line 1.
Use of uninitialized value $b in pattern match (m//) at -e line 1.
#####

Does the presence of these latter, more familiar, warnings mean that the
original problem is fixed?

As I noted in the other message, the change comes with commit 74529a4
but it's not clear why that commit causes the change.

Hence I'm confident to say that it fixes the *symptoms*. I'm not confident to
say that it actually fixes the bug.

Nicholas Clark

p5pRT · 2013-01-29T16:54:33Z

From @iabyn

On Sat, Jan 26, 2013 at 06:12:46PM +0000, Nicholas Clark wrote:

On Sat, Jan 26, 2013 at 09:42:28AM -0800, Karl Williamson via RT wrote:
On Tue May 18 14:07:44 2010, chorny wrote:
Same cryptic error on 5.12.0.

On Fri Aug 15 05:06:11 2003, abigail@abigail.nl wrote:
$ perl \-wle '$$a\, $b$ =~ $0\, 0$'
Too many arguments for regexp internal reset at \-e line 1\, at EOF
These no longer generate these error messages. Is there any reason to
keep this ticket open?

A bisect shows that it was fixed by this commit:

commit 74529a4
Author: David Mitchell <davem@iabyn.com>
Date: Fri Aug 19 12:10:01 2011 +0100
add Perl\_re\_op\_compile function

Actually, the bug is still present, but has metastasised.

The regcreset op is not normally present any more; it's been re-purposed
to reset taint status when building a run-time regex, whereas it used to
be used to initialise the re_eval count.

So you can still get the old bug as follows (make it taint and runtime):

$ ./perl -T -e'""=~ ($a,$b)'
Too many arguments for regexp internal reset at -e line 1, at EOF

But without the taint, there's some emergent behaviour, due to the way
that regcomp was turned into a listop; so /a$b/ changed from being

regcomp('a' . $b)

to

regcomp('a', $b)

Using a list on the RHS of the bind allows you to expose this new
behaviour. In particular,

=~ ("a", "b", "c")

is compile-time treated as

=~ "abc"

while

=~ ($a, $b, $c)

is run-time treated as

=~ $c

So there are some inconsistencies here that need ironing out.

We'll need to decide whether =~(X,Y,Z) should resolve to =~Z or =~X.Y.Z;
I suspect that our hand might be forced by the implementation.

--
Any [programming] language that doesn't occasionally surprise the
novice will pay for it by continually surprising the expert.
-- Larry Wall

p5pRT · 2013-01-30T11:07:08Z

From @arc

Dave Mitchell <davem@iabyn.com> wrote:

We'll need to decide whether =~(X,Y,Z) should resolve to =~Z or =~X.Y.Z;
I suspect that our hand might be forced by the implementation.

I think it would be much more predictable for it to resolve to =~Z —
that way, it's just the usual scalar-context behaviour of the comma
operator. But I take your point about the exigencies of the
implementation.

--
Aaron Crane ** http://aaroncrane.co.uk/

p5pRT · 2016-03-15T20:05:48Z

From @demerphq

On Tue Jan 29 08:54:33 2013, davem wrote:

On Sat, Jan 26, 2013 at 06:12:46PM +0000, Nicholas Clark wrote:

On Sat, Jan 26, 2013 at 09:42:28AM -0800, Karl Williamson via RT
wrote:

On Tue May 18 14:07:44 2010, chorny wrote:

Same cryptic error on 5.12.0.

On Fri Aug 15 05:06:11 2003, abigail@abigail.nl wrote:

$ perl -wle '($a, $b) =~ (0, 0)'
Too many arguments for regexp internal reset at -e line 1, at
EOF

These no longer generate these error messages. Is there any reason
to
keep this ticket open?

A bisect shows that it was fixed by this commit:

commit 74529a4
Author: David Mitchell <davem@iabyn.com>
Date: Fri Aug 19 12:10:01 2011 +0100

add Perl_re_op_compile function

Actually, the bug is still present, but has metastasised.

The regcreset op is not normally present any more; it's been re-
purposed
to reset taint status when building a run-time regex, whereas it used
to
be used to initialise the re_eval count.

So you can still get the old bug as follows (make it taint and
runtime):

$ ./perl -T -e'""=~ ($a,$b)'
Too many arguments for regexp internal reset at -e line 1, at EOF

But without the taint, there's some emergent behaviour, due to the way
that regcomp was turned into a listop; so /a$b/ changed from being

regcomp('a' . $b)

to

regcomp('a', $b)

Using a list on the RHS of the bind allows you to expose this new
behaviour. In particular,

=~ ("a", "b", "c")

is compile-time treated as

=~ "abc"

while

=~ ($a, $b, $c)

is run-time treated as

=~ $c

So there are some inconsistencies here that need ironing out.

We'll need to decide whether =~(X,Y,Z) should resolve to =~Z or
=~X.Y.Z;
I suspect that our hand might be forced by the implementation.

Just a ping about this issue. We still have it in latest perl 12 years later.

Perhaps the least we could do is provide a better error message?

Yves

khwilliamson · 2019-11-26T20:03:24Z

Suggest a better message and I will implement it

p5pRT added Severity Low distro-Linux type-core type-regex labels Oct 18, 2019

p5pRT added the khw label Oct 25, 2019

toddr removed the khw label Oct 25, 2019

xenu removed the affects-5.8 label Nov 19, 2021

xenu removed the Severity Low label Dec 29, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Confused regex parsing of lists #6993

Confused regex parsing of lists #6993

p5pRT commented Dec 18, 2003

p5pRT commented Aug 15, 2003

p5pRT commented Aug 16, 2003

p5pRT commented Aug 16, 2003

p5pRT commented Aug 17, 2003

p5pRT commented Dec 18, 2003

p5pRT commented Dec 20, 2003

p5pRT commented Dec 20, 2003

p5pRT commented Dec 20, 2003

p5pRT commented May 18, 2010

p5pRT commented May 18, 2010

p5pRT commented Jan 26, 2013

p5pRT commented Jan 26, 2013

p5pRT commented Jan 26, 2013

p5pRT commented Jan 26, 2013

p5pRT commented Jan 29, 2013

p5pRT commented Jan 30, 2013

p5pRT commented Mar 15, 2016

khwilliamson commented Nov 26, 2019

Confused regex parsing of lists #6993

Confused regex parsing of lists #6993

Comments

p5pRT commented Dec 18, 2003

p5pRT commented Aug 15, 2003

From @Abigail

Created by @Abigail

p5pRT commented Aug 16, 2003

From enache@rdslink.ro

p5pRT commented Aug 16, 2003

From @rgs

p5pRT commented Aug 17, 2003

From enache@rdslink.ro

p5pRT commented Dec 18, 2003

From perl-5.8.0@ton.iguana.be

Created by perl-5.8.0@ton.iguana.be

p5pRT commented Dec 20, 2003

From enache@rdslink.ro

p5pRT commented Dec 20, 2003

From enache@rdslink.ro

p5pRT commented Dec 20, 2003

From perl5-porters@ton.iguana.be

p5pRT commented May 18, 2010

From @chorny

p5pRT commented May 18, 2010

From [Unknown Contact. See original ticket]

p5pRT commented Jan 26, 2013

From @khwilliamson

p5pRT commented Jan 26, 2013

From @nwc10

p5pRT commented Jan 26, 2013

From @jkeenan

p5pRT commented Jan 26, 2013

From @nwc10

p5pRT commented Jan 29, 2013

From @iabyn

p5pRT commented Jan 30, 2013

From @arc

p5pRT commented Mar 15, 2016

From @demerphq

khwilliamson commented Nov 26, 2019