Skip Menu |

This queue is for tickets about the Getopt-Euclid CPAN distribution.

Report information
The Basics
Id: 34200
Status: resolved
Priority: 0/
Queue: Getopt-Euclid

People
Owner: Nobody in particular
Requestors: djerius [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: v0.2.0
Fixed in: (no value)



Subject: Incompatibility with Regexp::Common
I'd like to use Regexp::Common to validate parameter values, but so far haven't been succesful. I load the modules as such: use Regexp::Common qw/number/; use Getopt::Euclid qw( :minimal_keys ); As a silly example, if I write the spec as delta.type: /$RE{num}{real}/ I get the result: Getopt::Euclid: Unknown type (/$RE{num}{real}/) in specification: --delta <delta> | -d <delta> If I write it as delta.type: string, delta =~ /$RE{num}{real}/ I get the result: Getopt::Euclid: Invalid .type constraint: delta.type: string, /$RE{num}{real}/ (Global symbol "%RE" requires explicit package name at (eval 7) line 1, <$fh> line 1. ) I tried runtime loading of Getopt::Euclid (in case for some reason Regexp::Common loaded things on demand somehow, which it doesn't look like it does): use Regexp::Common qw( number ); print "it's real!\n" if "33.2" =~ /$RE{num}{real}/; eval 'use Getopt::Euclid; 1;' or die $@; with the following results: % perl ~/tmp/goe it's real! Getopt::Euclid: Invalid .type constraint: delta.type: string, delta =~ /$RE{num}{real}/ (Global symbol "%RE" requires explicit package name at (eval 8) line 1, <$fh> line 1. ) BEGIN failed--compilation aborted at (eval 2) line 1. Complete code follows: #!/usr/bin/perl use strict; use warnings; use Regexp::Common qw( number ); print "it's real!\n" if "33.2" =~ /$RE{num}{real}/; eval 'use Getopt::Euclid; 1;' or die $@; __END__ =head1 OPTIONS =over =item --delta <delta> | -d <delta> The string used to prefix the output file name(s). =for Euclid delta.type: string, delta =~ /$RE{num}{real}/ delta.default: +2 =back
Subject: Re: [rt.cpan.org #34200] Incompatibility with Regexp::Common
Date: Thu, 20 Mar 2008 16:23:00 +1100
To: bug-Getopt-Euclid [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
Diab Jerius via RT wrote: Show quoted text
> I'd like to use Regexp::Common to validate parameter values, but so far > haven't been succesful. I load the modules as such: > > use Regexp::Common qw/number/; > use Getopt::Euclid qw( :minimal_keys );
The problem is that Getopt::Euclid does not do its command-line parsing in the 'main' package (i.e. where you exported %RE to from Regexp::Common). Arguably that's wrong, and I'll look at changing it in a future release. For now, the workaround is to use a fully qualified name: =for Euclid delta.type: string, delta =~ /$main::RE{num}{real}/ delta.default: +2 Damian PS: I received all your other bug reports too, for which I'm most grateful. However, my father-in-law has just had a heart attack, so I'm not going to have any time to address them in the immediate future. I apologize for that.
Subject: Re: [rt.cpan.org #34200] Incompatibility with Regexp::Common
Date: Fri, 21 Mar 2008 15:38:48 -0400
To: bug-Getopt-Euclid [...] rt.cpan.org
From: Diab Jerius <dj [...] head.cfa.harvard.edu>
On Thu, 2008-03-20 at 01:23 -0400, damian@conway.org via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=34200 > > > Diab Jerius via RT wrote: >
> > I'd like to use Regexp::Common to validate parameter values, but so far > > haven't been succesful. I load the modules as such: > > > > use Regexp::Common qw/number/; > > use Getopt::Euclid qw( :minimal_keys );
> > The problem is that Getopt::Euclid does not do its command-line parsing in the > 'main' package (i.e. where you exported %RE to from Regexp::Common). > Arguably that's wrong, and I'll look at changing it in a future release. > > For now, the workaround is to use a fully qualified name: > > =for Euclid > delta.type: string, delta =~ /$main::RE{num}{real}/ > delta.default: +2 > > Damian > > > PS: I received all your other bug reports too, for which I'm most grateful. > However, my father-in-law has just had a heart attack, so I'm not going > to have any time to address them in the immediate future. I apologize > for that.
Thank you for taking the time to respond during what must surely be hectic and stressful times. I hope that all goes well in your father-in-law's recovery. Diab
Thanks for the report. I fixed this bug almost 2 months ago, in version 0.2.5. Florent