in reply to Re^2: Is it ever legitimate to override $^O ?
in thread Is it ever legitimate to override $^O ?

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

[download]

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Replies are listed 'Best First'.
Re^4: Is it ever legitimate to override $^O ?
by syphilis (Archbishop) on Aug 03, 2022 at 02:01 UTC 
    perl -MConfig -wE "say $Config{'osname'}; $Config{'osname'} = 'Unix'; 
+say $Config{'osname'}"

MSWin32
Unix

    [download]

    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

    [download]
    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.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom