and apparently $fh is an IO::File object ... in other words, you've just called object method "print" on an IO::File object. Is that what you intended ?Anyway ... hence tobyink's suggestion.

It all looks very weird to me - I can't see how $fh has come to be an IO::File object in the first place.And it's rather odd for a test suite to be doing anything with lib/P.pm - normally the test suite would be using the P.pm that has been put into blib.

The module also fails to pass its test on Windows. I'm guessing you already know that (as that test suite does some things that simply won't work on Windows).

but the fail on 512/Bsd and not linux and not 514 or 516 -- previous report had many more fails on other clients... that only this one is causing probs -- what is diff about this combo? That's what's stumped me...

Have no easy way to test this on a BSD5.12 system though and am not sure if
a change like above wouldn't cause probs on other systems.

. As for $fh... P takes 'globs'. or IO handles.
Does that answer your Q?
----
later

If I added IO::Handle/IO::File... and if that worked, it would seem to indicated
that IO::Handle doesn't have an @ISA relation with IO::Handle. How likely is that on 1 platform?

CPAN test reports are like money - 95% of it is controlled by just 5% of the population (or something like that).

There are a small handful of individuals who submit a vast number of CPAN test reports. Check the failure reports you are getting - are they all from the same person? If so, perhaps their system is configured unusually.

Otherwise, I'd personally just document the problem and then forget about it. Something like:

=head1 BUGS
The test suite fails in Perl 5.12 on BSD operating systems.
Upgrading to Perl 5.14 or above should solve this problem.
Patches to fix the issue would be joyfully accepted.

Um... so everyone who uses 'print' or 'printf' needed to use IO::Handle? I doubt that is what you mean, is it?

In any case, changing the code from '$fh->print' to 'print $fh' seems to have fixed the problem. Of *course* it makes sense -- it's perl!
:-)

That uncovered one last (??*crossing fingers*??) bug where the 'cat' was involved, which was unrelated to the 'rev', which I just supplied in my test directory (in a perl-1-liner script).simulated in a perl 1-liner:

The 'cat' was for my STDERR test, which I cleaned up (and got rid of using 'cat' in testing...didn't want any Humane Society/PITA complaints). It's a split output, where the first part of the line put out by the 'generic example' code is on STDOUT, and the 2nd part is on STDERR... so I just run it twice for that test: