# from John Peacock
# on Tuesday 12 September 2006 03:30 am:
>Eric Wilhelm wrote:
>> Seriously, just skip anything that causes the least bit of trouble
>> and print a big warning about peRHl being of questionable
>> compatibility.
>
>Just FYI, it's not that RHE is incompatible; it is *too* compatible.
> The reason for the huge @INC list is that RedHat decided to upgrade
> Perl itself over the course of multiple releases of RedHat. They did
> this by including all previous binary-compatible directory trees into
> each release (e.g. 5.8.8 also includes the full core and site paths
> for 5.8.7, 5.8.6, etc).
But, they add 5.n.n directories which don't exist. When I change @INC
on a normal perl, I get automagic 5.n.n directories iff they exist. It
appears from the reports that peRHl adds "5.n.n"x12 regardless of
whether there's anything there.
>I think the only sane solution to this problem is to find some way to
>stop relying on shell expansion, which is the only place this is a
>problem.
Is there a better way to run something in a clean perl process? Jumping
through a lot of hoops? (e.g. a forked listener child started at BEGIN
{} or maybe printing a file full of "use lib 'foo'\nuse lib..." and
having run_perl_script() do -Mthatfile.) But this problem is likely to
bite on tests other than just M::B -- anywhere that system() is used is
subject to the same trouble.
I'll be the first to admit that system calls can turn flaky. Yet, we've
only ever seen this problem on RHEL? It seems to me that special-case
workarounds and/or punts are in order if anything.
--Eric
--
"Unthinking respect for authority is the greatest enemy of truth."
--Albert Einstein
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
