in reply to Is it ever legitimate to override $^O ?

Hello again syphilis,

some steps backward? Can this $^O be only some smoke in our eyes? t/01-basic.t .......... 1/78 Can't call method "relative" on an undefined value ...lets start again from this point:

# https://metacpan.org/release/KWILLIAMS/Path-Class-0.37/source/lib/Pa
+th/Class/Entity.pm#L65

sub resolve {
  my $self = shift;
  Carp::croak($! . " $self") unless -e $self;  # No such file or direc
+tory
  my $cleaned = $self->new( scalar Cwd::realpath($self->stringify) );
 
  # realpath() always returns absolute path, kind of annoying
  $cleaned = $cleaned->relative if $self->is_relative;                
+        # line 71 (76 in your modified version)
 
  %$self = %$cleaned;
  return $self;
}

[download]

So $cleaned is undefined at line 71 and it should be initialized in the line my $cleaned = $self->new( scalar Cwd::realpath($self->stringify) ); so going backward I'd verify:

So, maybe, the problem is not at all with Path::Class nor with (or maybe yes..) with assignement to $0 but within Cwd or File::Spec as they are heavily used in the background.

I mean: I tried to track back Cwd::realpath and this module also use $^O to decide what to do.

I'd also investigate which version of Cwd and File::Spec come with your testing distros of Perl.

As last point (maybe due to a dumb moment): the failing test is the first one: there are 78 tests and I checked them... the first one is.... ok(1) O_O is this one failing?!?

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^2: Is it ever legitimate to override $^O ? -- Cwd and File::Spec
by syphilis (Archbishop) on Aug 03, 2022 at 09:41 UTC
    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
[reply]
[d/l]
[select]
      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]

In Section Seekers of Perl Wisdom