Re: cpan mod test probs

G'day Linda,

You appear to have your answer regarding $ENV{PERL5OPT}. [As an aside, and really more for future reference, did you consider removing the hash element with delete rather than just assigning undef.]

For some additional information in this general area, have you seen "The CPAN Testers Wiki" and, in particular, its section "CPAN Authors FAQ".

-- Ken

Comment on Re: cpan mod test probs Select or Download Code

Replies are listed 'Best First'.
Re^2: cpan mod test probs by perl-diddler (Chaplain) on Nov 08, 2013 at 17:09 UTC
Didn't really consider it in this instance. Was more focused on getting it to work first, then I worry about optimizing later, if needed. I don't really have a good answer other than to fail if -Mutf8 is set in the ENV since the harness doesn't handle it. It seems to think it is immune from utf8 being settable outside of it's documented calls and ignored "use utf8;" in the code. Looking at the code itself, the strings were being treated as latin1. If I followed it's instructions on using utf8 I ended up with the faulty latin1 bytes being re-encoded as utf8 -- a double encoding. It didn't seem to be able to deal with the case where it was already encoded. I can't report it as a bug unless I'm willing to come up with a trivial test case for it. I've reported problems with having unexpected settings in PERL5OPT before (Perl won't make properly, for example) and was told it wasn't their problem -- just don't set things in your ENV. C'est la vie.	[reply]

Replies are listed 'Best First'.

Re^2: cpan mod test probs
by perl-diddler (Chaplain) on Nov 08, 2013 at 17:09 UTC

I don't really have a good answer other than to fail if -Mutf8 is set in the ENV since the harness doesn't handle it. It seems to think it is immune from utf8 being settable outside of it's documented calls and ignored "use utf8;" in the code.

Looking at the code itself, the strings were being treated as latin1. If I followed it's instructions on using utf8 I ended up with the faulty latin1 bytes being re-encoded as utf8 -- a double encoding. It didn't seem to be able to deal with the case where it was already encoded. I can't report it as a bug unless I'm willing to come up with a trivial test case for it.

I've reported problems with having unexpected settings in PERL5OPT before (Perl won't make properly, for example) and was told it wasn't their problem -- just don't set things in your ENV. C'est la vie.

[reply]