Re: Getopt::Euclid victim of 5.10 upgrade
by andreas1234567 (Vicar) on Feb 13, 2009 at 06:23 UTC
|
Getopt::Euclid has
21 active bugs and the most recent change to the resolved bugs were 2 years ago. You depend on code that is most likely unmaintained (the assumption is mine and mine alone).
I would look for replacements for Getopt::Euclid if I were you, even if it requires a major rewrite of your application.
--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
| [reply] [Watch: Dir/Any] |
|
He could always seek the ACLs to be a maintainer himself.
--
In Bob We Trust, All Others Bring Data.
| [reply] [Watch: Dir/Any] |
|
It was active when I started using it. That's part of the problem; all my new scripts over the last couple of years now use it. Unfortunately, I suspect replacing Euclid is what I'm going to have to do.
| [reply] [Watch: Dir/Any] |
|
You're an experienced user of the module, and the way you presented the problem shows you definitely have some skill. Perhaps fixing Getopt::Euclid really would be a better use of your time than reworking your application. Even if you can't/shouldn't/won't take over maintaining G::E on CPAN, you can still post your solution as a patch on rt.
cat >~/.sig </dev/interesting
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] |
|
Is there any other package that have the same function as Getopt::Euclid
I don't know. What's the problem with Getopt::Euclid ? Version v0.2.3 seems to be working fine for me on Cygwin 1.7.5 (perl 5.10.1).
Getopt::Euclid is now apparently being maintained - if you have an issue with it, a bug report might be the quickest way to get that issue sorted.
Cheers, Rob
| [reply] [Watch: Dir/Any] |
Re: Getopt::Euclid victim of 5.10 upgrade
by ikegami (Patriarch) on Feb 13, 2009 at 01:16 UTC
|
Does it work if you change "\x0E" to "^N"? Shouldn't matter, though.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
You are right. It was supposed to be (and now is) $^N. It got mangled when I cut-n-pasted the code and I did not notice it in the post preview.
| [reply] [Watch: Dir/Any] |
|
Did it help? Perl should accept both, IIRC
| [reply] [Watch: Dir/Any] |
Re: Getopt::Euclid victim of 5.10 upgrade
by JavaFan (Canon) on Feb 13, 2009 at 10:45 UTC
|
Perl 5.8.9 on linux:
$ARGV = {
'WHEN' => '12:34'
};
$string = 'It is thyme';
and
Perl 5.10.0 on linux:
$ARGV = {
'WHEN' => '12:34'
};
$string = 'It is thyme';
Considering that the MSWin32 Perl also gives you what you want, I'd say you encountered a bug in the cygwin port. It may be worth sending in a bug report; preferably with the code fragment turned into a test.
As for a fix, I've one suggestion. Try turning the my $ARGV into local %ARGV, and use a fully qualified path when refering to $ARGV{WHEN}. But that's just a guess, and since my perl doesn't have the bug in the first place, I cannot test whether it makes a difference. | [reply] [Watch: Dir/Any] [d/l] [select] |
|
hektor ~ $ ./retest
Perl 5.10.0 on darwin:
$ARGV = {
'WHEN' => undef
};
$string = 'It is thyme';
hektor ~ $ /usr/bin/perl retest
Perl 5.8.8 on darwin:
$ARGV = {
'WHEN' => '12:34'
};
$string = 'It is thyme';
A quick second look: I'm now thinking it has something to do with the configuration. These two are from the same machine (Debian Lenny), but they're both 5.10.0. Nevertheless, the results differ. The first 5.10.0 is once again my own build, but the second is Debian's. (I applied a few patches to my own, particularly one to stop a regular expression related memory leak, but I believe that Debian has that patch as well - and more.)
telemachus ~ $ perl testre
Perl 5.10.0 on linux:
$ARGV = {
'WHEN' => undef
};
$string = 'It is thyme';
telemachus ~ $ /usr/bin/perl testre
Perl 5.10.0 on linux:
$ARGV = {
'WHEN' => '12:34'
};
$string = 'It is thyme';
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Thank you all for your help and insight. Unfortunately, I see little
recourse but to abandon my use of Getopt::Euclid. I'm not going to
rewrite existing scripts for now, but I won't use Getopt::Euclid for a
new research project I am starting.
The straw that broke the camel's back (so to speak) is the
inconsistent failures. It works for me on OS X with perl 5.10 but fails
for telemachus. Further, it works with one build of perl 5.10.0 on linux
and fails for a different build of 5.10.0 on the same system.
I lack time and motivation to trace the failure all the way back to
perl build configuration settings, especially since it appears that
Damian Conway has abandoned Getopt::Euclid.
Once again, thank you for your help.
Scott
P.S. I rewrote my sample code to be a proper Test::More test script.
Furthermore, I also reverted to the original regular expression, in case
my simplification introduced its own errors.
That code, when run twice on my system, reports:
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Getopt::Euclid victim of 5.10 upgrade
by parv (Parson) on Feb 13, 2009 at 06:34 UTC
|
I am curious how would changing to ActiveState Perl change things. Is it that ActiveState provide fixes (for your situation) for the Getopt::Euclid module? | [reply] [Watch: Dir/Any] |
|
It works with cygwin perl 5.8. It works with ActiveState 5.8 and 5.10. It works with all versions I use on OS X. It is only cygwin's default perl, version 5.10, that has revealed the 'experimental' regex sensitivity.
| [reply] [Watch: Dir/Any] |
|
I don't think this is related to the "experimental" nature of (?{ }) either.
| [reply] [Watch: Dir/Any] [d/l] |
|
It's been shown to work in linux and earlier version, so I don't think so. I think something broke in cygwin.
| [reply] [Watch: Dir/Any] |