Re^3: Is it ever legitimate to override $^O ?

[Discipulus]

Hello syphilis,

> whereas $Config{osname} is permanently set in stone and attempting to assign a value to it should be a fatal compile-time error.

perl -MConfig -wE "say $Config{'osname'}; $Config{'osname'} = 'Unix'; 
+say $Config{'osname'}"

MSWin32
Unix

L*

[syphilis]

perl -MConfig -wE "say $Config{'osname'}; $Config{'osname'} = 'Unix'; 
+say $Config{'osname'}"

MSWin32
Unix


Well ... when I build perl from official source (which I've done for perl-5.8.8 onwards), %Config is always readonly:

> perl -MConfig -wle "$Config{osname} = 'MSWin32';"
%Config::Config is read-only

But I can see on my portable Strawberry builds that their %Config is indeed writeable. (I hadn't noticed that - thanks for pointing it out.)
Maybe that's how they deal with being unable to know perl's final destination.
I don't think it should be necessary for them to do this ... and it feels a bit unsafe (to me) to be dealing with it in this way.
I have a notion (unverified) that the location-dependent %Config keys can be reset appropriately by post-installation editing of lib/Config_heavy.pl.
Do Strawberry's msi installations also allow %Config to be overwritten ? (I don't have such an installation available.)

In any case, I don't think it has a bearing on this issue I'm dealing with.
I can see that there's no issue on perl-5.32.x, irrespective of whether %Config is readonly.
I know that the problem arises on perl-5.34.0 and later when %Config is readonly.
Even if, by some unlikely chance, the issue is avoided when %Config is not readonly, there's still an issue to deal with.

And I'm still unsure what needs fixing. I'll try to contact Ken Williams (as kcott suggested).

Cheers,
Rob

Update: I should probably point out that I don't see any problem with Path::Class itself - it's just that t/01-basic.t is presenting an issue that probably has nothing to do with Path::Class.