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

no clues by me, only other doubts..

In the very first place I dont understand why a module aimed to help with path and filenames plays so dirty on testing, faking a Unix mode

Second, as I dont have any strawberry available newer than 5.32 I played a bit with the t/01-basic.t and I discovered it fails in the same way even with this modified part:

use Config;
BEGIN {
  #$^O = 'Unix'; # Test in Unix mode
   $Config{'osname'} = 'Unix';
   warn "DEBUG: config: ",$Config{'osname'}," -- \$^O: $^O\n";
}
[download]

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

In perlvar I read: $^O .. The value is identical to $Config{'osname'}. They are identical but not bound.

Infact the module you are talking about rely on the core module File::Spec (..yes, boring to use but works very well) and it simply inspect $^O as you can see. And yes you can also try $^O = ''; to fake the Unix mode.

With my poor understanding I can find nothing in perldelta about osname nor about $^O

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

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.

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

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


Keep It Simple, Stupid
	PerlMonks