in reply to Re: Is it ever legitimate to override $^O ? -- Cwd and File::Spec
in thread Is it ever legitimate to override $^O ?

Yes - I had started off by checking most of those things. (That was how line 71 became line 76 ;-)
Everything looked fine, except that $cleaned was not defined.
It was actually quite some time before I looked at the test script itself and noticed the $^O override.

File/Spec.pm contains very little code - and it certainly seems to be inviting this override that t/01-basic.t uses.
So I decided to investigate some basic behaviour of File::Spec, without any reference to Path::Class. I used this script: 
# fake_os.pl

BEGIN {
  $^O = 'Unix';
}

use strict;
use warnings;
use File::Spec;

my $x = File::Spec->catfile('a', 'b', 'c');

print $x;

[download]
I find that on both perl-5.32 and 5.34, this script outputs 'a/b/c' as expected.
If I comment out the BEGIN block, then the script outputs 'a\b\c' as expected - on both perl-5.32 and perl-5.34. What is odd is that if I simply load Test::Harness, then on both perl-5.32 and 5.34 I always get 'a\b\c' even when the BEGIN block is included: 
C:\_32\pscrpt\file-spec>perl fake_os.pl
a/b/c
C:\_32\pscrpt\file-spec>perl -MTest::Harness fake_os.pl
a\b\c

[download]
I think that demonstrates that there might be some fragility around overriding $^O, though it doesn't really explain much about the behaviour of t/01-basic.t.

I think it's a pity that File::Spec invites users to mess with the path formatting by fiddling with $^O.
Surely it would be better if there was a function to call or an environment variable to set ... or something else that doesn't involve fiddling with $^O.

I think I might just file bug reports against both perl (based on the demo of the Test::Harness interference) and Path::Class ... and see where it all ends up.

I've just tried my fake_os.pl on Ubuntu with $^O = 'Win32'; and it just ignores that and gives the Unix style 'a/b/c' (on both perl-5.32 and 5.36).(I think that's intended behaviour.)
I totally buggered that up. I can get Win32 path formatting with fake_os.pl on Ubuntu if I specify $^O = 'MSWin32' .
Again, it doesn't work if the Test::Harness is loaded.
I think I'm just fiddling about with a heap of rubbish ...

Update: Forgot to mention that I did hack File::Spec on Windows perl-5.34 such that 'Unix' was hard coded in, and $^O didn't need to be altered. In that case the t/01-basic.t script ran fine and passed all tests.
To me, that shows that the problem with t/01-basic.t is not that 'Unix' formatting is being selected - it's because $^O is being messed with.
I'll post again with links to relevant bug reports once they have been filed.
Thanks for the interest that has been shown.

Cheers,
Rob

Replies are listed 'Best First'.
Re^3: Is it ever legitimate to override $^O ? -- Cwd
by Discipulus (Canon) on Aug 03, 2022 at 10:27 UTC
    Ah!

    ..and Cwd that my spider sense supposed the first to be charged?

    while your fakOS.pl behaves the same way for me.. the following Cwd version acts in the opposite way

    C:>cat fakeOS.pl

BEGIN {
  $^O = 'Unix';
}

use strict;
use warnings;
use Cwd 'abs_path';

my $abs_path = abs_path('.');
print $abs_path;


C:>perl fakeOS.pl
 C:\EX_D\ulisseDUE

C:>perl -MTest::Harness fakeOS.pl
 C:/EX_D/ulisseDUE

    [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]
[select]
      the following Cwd version acts in the opposite way

      Heh ... that's pretty flakey, too. (I see the same.)

      What I'd like to find is some code where the behaviour changes between perl-5.32 and perl-5.34.
      Apart from t/01-basic.t, everything I've tested (including your fakeOS.pl) is doing the same thing on both of those versions of perl.

      If I take your fakeOS.pl, change $^O = 'Unix'; to $^O = 'MSWin32' and run it on Ubuntu-20.04, I get: 
      $ perl fakeOS.pl
Use of uninitialized value $abs_path in concatenation (.) or string at
+ fakeOS.pl line 10.

      [download]
      and 
      $ perl -MTest::Harness fakeOS.pl
/home/sisyphus/pscrpt

      [download]
      Again, however, it's the same behaviour on perl-5.32 and perl-5.34.
      Interestingly, that error message when run without loading Test::Harness hints at being perhaps connected to the failure that t/01-basic.t is triggering on perl-5.34 and later.

      Dunno ... I think I just need to find the time to make one or two bug reports and let the experts sort it out.

      Cheers,
      Rob
[reply]
[d/l]
[select]
[reply]

In Section Seekers of Perl Wisdom