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

So $Config{'osname'} and $^O are independent and the above code is only influenced by $^O.

Yes - initially $Config{osname} and $^O are identical. But $^O can be altered (is writeable) whereas $Config{osname} is permanently set in stone and attempting to assign a value to it should be a fatal compile-time error.

And yes you can also try $^O = ''; to fake the Unix mode.

I didn't know that. So I tried specifying $^O = ''; in t/01-basic.t but it didn't help wrt perl-5.34.0 and later :-(

As last doubt I have noting at Entity.pm line 76. ..merely a blank line after the sub resolve ending

Yeah - it should be line 71 (I think).
As I've (now) noted elsewhere in this thread, I made changes (comments) in Entity.pm that did not alter the code but did bugger up the line numbering. Sorry 'bout that.

Cheers,
Rob

Comment on Re^2: Is it ever legitimate to override $^O ? Download Code

Replies are listed 'Best First'.
Re^3: Is it ever legitimate to override $^O ? by Discipulus (Canon) on Aug 02, 2022 at 15:24 UTC
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.	[reply] [d/l]
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]


more useful options
	PerlMonks