Bug #106552 for Object-InsideOut: Seems to need read access to current directory

Wed Aug 19 23:08:33 2015 se456 [...] rohan.id.au - Ticket created

Subject:	Seems to need read access to current directory
Date:	Thu, 20 Aug 2015 11:08:11 +0800
To:	bug-Object-InsideOut [...] rt.cpan.org
From:	se456 [...] rohan.id.au

I've noticed that Object::InsideOut v3.98 fails when the current directory is not readable by the user running the Perl binary. Most Perl modules don't have this requirement, and so OIO creates a very cryptic error message when you run it in such circumstances.

e.g.

This fails:

root@slushy:/# cd /root && setuidgid www-data perl -I/home/tdev/local/lib/perl5 -MObject::InsideOut
Can't locate OIO.pm:   Permission denied at /usr/share/perl/5.20/base.pm line 97.
    ...propagated at /usr/share/perl/5.20/base.pm line 106.
BEGIN failed--compilation aborted at (eval 5) line 3.
BEGIN failed--compilation aborted at /home/tdev/local/lib/perl5/Object/InsideOut/Exception.pm line 64.
Compilation failed in require at /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11.
BEGIN failed--compilation aborted at /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11.
Compilation failed in require.
BEGIN failed--compilation aborted.

FYI setuidgid is a utility that comes with daemontools. Here's its man page:

SYNOPSIS
       setuidgid account child

DESCRIPTION
       account is a single argument. child consists of one or more arguments.

       setuidgid sets its uid and gid to account's uid and gid, removing all supplementary groups. It then runs child.

       setuidgid cannot be run by anyone other than root.

But this works:

root@slushy:~# cd / && setuidgid www-data perl -I/home/tdev/local/lib/perl5 -MObject::InsideOut
OIO::Code error: 'import' invoked from 'main'
Info: Can't use 'use Object::InsideOut;' or 'Object::InsideOut->import();' inside application code
Package: main
File: -
Line: 0

Trace begun at - line 0
main::BEGIN at - line 0
eval {...} at - line 0
BEGIN failed--compilation aborted.

(I realise that this second error message about "import invoked from main" is probably normal -- I'm not concerned about that.)

root@slushy:/# ls -ld /root
drwx------ 11 root root 4096 Aug 20 10:49 /root
root@slushy:/# ls -ld /
drwxr-xr-x 29 root root 4096 Apr 10 13:40 /

I think this is a bug and if possible, whatever's creating this requirement should be removed.

Thanks,

Rohan.

Thu Aug 20 09:24:38 2015 jdhedden [...] cpan.org - Correspondence added

There is no bug. Perl includes '.' (the current directory) in the paths it uses to find modules (i.e., @INC). If the current directory is not readable, this will produce an error. The workaround is to add the following to your code before any 'use ...' statements: BEGIN { pop(@INC) } The OIO module can only be 'use'd inside a package. This is producing the other error. A proper working example of what you're trying to work through is the following: mkdir noread cd noread chmod 0 . perl -e 'BEGIN { pop(@INC) } package foo; use Object::InsideOut; package main; print "hello\n"' The above produces no errors, and prints out 'hello' as expected. On 2015-08-19 23:08:33, se456@rohan.id.au wrote: Show quoted text

> I've noticed that Object::InsideOut v3.98 fails when the current > directory is > not readable by the user running the Perl binary. Most Perl modules > don't have > this requirement, and so OIO creates a very cryptic error message when > you run > it in such circumstances. > > e.g. > > This fails: > > root@slushy:/# cd /root && setuidgid www-data perl > -I/home/tdev/local/lib/perl5 > -MObject::InsideOut > Can't locate OIO.pm: Permission denied at /usr/share/perl/5.20/base.pm > line 97. > ...propagated at /usr/share/perl/5.20/base.pm line 106. > BEGIN failed--compilation aborted at (eval 5) line 3. > BEGIN failed--compilation aborted at > /home/tdev/local/lib/perl5/Object/InsideOut/Exception.pm line 64. > Compilation failed in require at > /home/tdev/local/lib/perl5/Object/InsideOut.pm > line 11. > BEGIN failed--compilation aborted at > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > Compilation failed in require. > BEGIN failed--compilation aborted. > > > FYI setuidgid is a utility that comes with daemontools. Here's its man > page: > > SYNOPSIS > setuidgid account child > > DESCRIPTION > account is a single argument. child consists of one or more arguments. > > setuidgid sets its uid and gid to account's uid and gid, removing all > supplementary groups. It then runs child. > > setuidgid cannot be run by anyone other than root. > > > > > But this works: > > root@slushy:~# cd / && setuidgid www-data perl > -I/home/tdev/local/lib/perl5 > -MObject::InsideOut > OIO::Code error: 'import' invoked from 'main' > Info: Can't use 'use Object::InsideOut;' or 'Object::InsideOut-

> >import();'

> inside application code > Package: main > File: - > Line: 0 > > > Trace begun at - line 0 > main::BEGIN at - line 0 > eval {...} at - line 0 > BEGIN failed--compilation aborted. > > (I realise that this second error message about "import invoked from > main" is > probably normal -- I'm not concerned about that.) > > root@slushy:/# ls -ld /root > drwx------ 11 root root 4096 Aug 20 10:49 /root > root@slushy:/# ls -ld / > drwxr-xr-x 29 root root 4096 Apr 10 13:40 / > > I think this is a bug and if possible, whatever's creating this > requirement > should be removed. > > Thanks, > > Rohan.

Thu Aug 20 09:24:38 2015 The RT System itself - Status changed from 'new' to 'open'

Thu Aug 20 09:24:40 2015 jdhedden [...] cpan.org - Status changed from 'open' to 'rejected'

Fri Jan 29 04:04:29 2016 se456 [...] rohan.id.au - Correspondence added

Subject:	Re: [rt.cpan.org #106552] Seems to need read access to current directory
Date:	Fri, 29 Jan 2016 17:04:13 +0800
To:	bug-Object-InsideOut [...] rt.cpan.org
From:	se456 [...] rohan.id.au

Thankyou for taking the time earlier to read and respond to my bug report. I've finally had a chance to digest what you wrote and I just wanted to check I understood you correctly. You are correct that "." is in @INC, however I believe that Object::InsideOut is unusual for producing a fatal compile-time error when a non-readable directory is in @INC. This is the only CPAN module I have encountered that is sensitive about this. mkdir noread cd noread chmod 0 . perl -I/home/tdev/local/lib/perl5 -e 'package foo; use Moose; package main; print "hello\n"' hello perl -I/home/tdev/local/lib/perl5 -e 'package foo; use CGI; package main; print "hello\n"' hello perl -I/home/tdev/local/lib/perl5 -e 'package foo; use XML::LibXML; package main; print "hello\n"' hello perl -I/home/tdev/local/lib/perl5 -e 'package foo; use Object::InsideOut; package main; print "hello\n"' Can't locate OIO.pm: ./OIO.pm: Permission denied at /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line 99. ...propagated at /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line 108. BEGIN failed--compilation aborted at (eval 5) line 3. BEGIN failed--compilation aborted at /home/tdev/local/lib/perl5/Object/InsideOut/Exception.pm line 64. Compilation failed in require at /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. BEGIN failed--compilation aborted at /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. If you don't think this is a bug, then fine, but I personally find this behavior surprising. FYI, I use Object::InsideOut because it's a dependency for Math::Random::MT::Auto and running my script using cron is what led me to a situation where the current directory is unreadable. It was easily worked around, but took a while to diagnose.

Fri Jan 29 15:08:37 2016 SREZIC [...] cpan.org - Correspondence added

On 2016-01-29 04:04:29, se456@rohan.id.au wrote: Show quoted text

> Thankyou for taking the time earlier to read and respond to my bug > report. > I've finally had a chance to digest what you wrote and I just wanted > to check > I understood you correctly. > > You are correct that "." is in @INC, however I believe that > Object::InsideOut > is unusual for producing a fatal compile-time error when a non- > readable > directory is in @INC. This is the only CPAN module I have encountered > that is > sensitive about this. > > mkdir noread > cd noread > chmod 0 . > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use Moose; package > main; > print "hello\n"' > hello > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use CGI; package > main; > print "hello\n"' > hello > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use XML::LibXML; > package > main; print "hello\n"' > hello > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use > Object::InsideOut; > package main; print "hello\n"' > Can't locate OIO.pm: ./OIO.pm: Permission denied at > /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line > 99. > ...propagated at > /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line > 108. > BEGIN failed--compilation aborted at (eval 5) line 3. > BEGIN failed--compilation aborted at > /home/tdev/local/lib/perl5/Object/InsideOut/Exception.pm line 64. > Compilation failed in require at > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > BEGIN failed--compilation aborted at > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > Compilation failed in require at -e line 1. > BEGIN failed--compilation aborted at -e line 1. > > If you don't think this is a bug, then fine, but I personally find > this > behavior surprising. > > FYI, I use Object::InsideOut because it's a dependency for > Math::Random::MT::Auto and running my script using cron is what led me > to a > situation where the current directory is unreadable. It was easily > worked > around, but took a while to diagnose.

I think this is a bug, but deeper, in base.pm. It can be easily reproduced like this (after making the current directory unreadable): $ perl5.23.7 -e 'use base "Foo"' Can't locate Foo.pm: ./Foo.pm: Permission denied at /opt/perl-5.23.7/lib/site_perl/5.23.7/base.pm line 100. ...propagated at /opt/perl-5.23.7/lib/site_perl/5.23.7/base.pm line 109. BEGIN failed--compilation aborted at -e line 1. base.pm's code at this point: die if $@ && $@ !~ /^Can't locate \Q$fn\E .*? at .* line [0-9]+(?:, <[^>]*> (?:line|chunk) [0-9]+)?\.\n\z/s || $@ =~ /Compilation failed in require at .* line [0-9]+(?:, <[^>]*> (?:line|chunk) [0-9]+)?\.\n\z/; So the first ":" in the error message is unexpected here. parent.pm seems to have the same problem.

Fri Jan 29 15:13:27 2016 jdhedden [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #106552] Seems to need read access to current directory
Date:	Fri, 29 Jan 2016 15:12:45 -0500
To:	bug-Object-InsideOut [...] rt.cpan.org
From:	"Jerry D. Hedden" <jdhedden [...] cpan.org>

I agree the behavior is surprising, however, it is not an OIO bug. I looked deeper into this. There is no OIO.pm. The OIO namespace is generated in Object/InsideOut/Exception.pm when it imports Exception::Class. Looking at Object/InsideOut/Exception.pm, I found that it generates code and then eval's it. That code generates a package for the OIO namespace. In the code, I see "use base qw($isa);" where $isa would be "OIO" in this case. The error comes from base.pm when it goes looking for the non-existent OIO.pm. That fact that OIO.pm does not exist is not a problem in and of itself. base.pm executes "eval { require $fn };" where $fn is "OIO.pm". If OIO.pm is determined not to exist, the code proceeds to other logic. In this case, however, the 'require' code is stymied by the directory permissions. The same thing would happen if OIO.pm did exists, but the user didn't have read permissions on it. This is the result of core perl behavior. It can be seen in detail from the following: Show quoted text

> mkdir foo > cd foo > echo 'package pkg; $VERSION = "1.00"; 1;' >pkg.pm

# Directory and file accessible to all Show quoted text

> perl -Mpkg -e 'print "$pkg::VERSION\n"'

1.00 Show quoted text

> sudo -u www-data perl -Mpkg -e 'print "$pkg::VERSION\n"'

1.00 # Owner read-only file Show quoted text

> chmod 600 pkg.pm > perl -Mpkg -e 'print "$pkg::VERSION\n"'

1.00 Show quoted text

> sudo -u www-data perl -Mpkg -e 'print "$pkg::VERSION\n"'

Can't locate pkg.pm: ./pkg.pm: Permission denied. BEGIN failed--compilation aborted. # Unreadable file Show quoted text

> chmod 000 pkg.pm > perl -Mpkg -e 'print "$pkg::VERSION\n"'

Can't locate pkg.pm: ./pkg.pm: Permission denied. BEGIN failed--compilation aborted. Show quoted text

> sudo -u www-data perl -Mpkg -e 'print "$pkg::VERSION\n"'

Can't locate pkg.pm: ./pkg.pm: Permission denied. BEGIN failed--compilation aborted. # Owner-only directory Show quoted text

> chmod 644 pkg.pm > chmod 700 . > perl -Mpkg -e 'print "$pkg::VERSION\n"'

1.00 Show quoted text

> sudo -u www-data perl -Mpkg -e 'print "$pkg::VERSION\n"'

Can't locate pkg.pm: ./pkg.pm: Permission denied. BEGIN failed--compilation aborted. Thus, the behavior you're reporting is not a bug in OIO itself. On Fri, Jan 29, 2016 at 4:04 AM, Rohan Carly via RT < bug-Object-InsideOut@rt.cpan.org> wrote: Show quoted text

> Queue: Object-InsideOut > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=106552 > > > Thankyou for taking the time earlier to read and respond to my bug report. > I've finally had a chance to digest what you wrote and I just wanted to > check > I understood you correctly. > > You are correct that "." is in @INC, however I believe that > Object::InsideOut > is unusual for producing a fatal compile-time error when a non-readable > directory is in @INC. This is the only CPAN module I have encountered that > is > sensitive about this. > > mkdir noread > cd noread > chmod 0 . > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use Moose; package main; > print "hello\n"' > hello > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use CGI; package main; > print "hello\n"' > hello > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use XML::LibXML; package > main; print "hello\n"' > hello > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use Object::InsideOut; > package main; print "hello\n"' > Can't locate OIO.pm: ./OIO.pm: Permission denied at > /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line 99. > ...propagated at > /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line 108. > BEGIN failed--compilation aborted at (eval 5) line 3. > BEGIN failed--compilation aborted at > /home/tdev/local/lib/perl5/Object/InsideOut/Exception.pm line 64. > Compilation failed in require at > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > BEGIN failed--compilation aborted at > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > Compilation failed in require at -e line 1. > BEGIN failed--compilation aborted at -e line 1. > > If you don't think this is a bug, then fine, but I personally find this > behavior surprising. > > FYI, I use Object::InsideOut because it's a dependency for > Math::Random::MT::Auto and running my script using cron is what led me to a > situation where the current directory is unreadable. It was easily worked > around, but took a while to diagnose. > >

Fri Jan 29 15:17:01 2016 jdhedden [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #106552] Seems to need read access to current directory
Date:	Fri, 29 Jan 2016 15:16:20 -0500
To:	bug-Object-InsideOut [...] rt.cpan.org
From:	"Jerry D. Hedden" <jdhedden [...] cpan.org>

I don't see this as a bug in base.pm. It stems from the 'require' directive. Show quoted text

> echo 'package pkg; $VERSION = "1.00"; 1;' >pkg.pm > perl -e 'require pkg' > chmod 000 pkg.pm > perl -e 'require pkg'

Can't locate pkg.pm: ./pkg.pm: Permission denied at -e line 1. When permissions are not "correct" then perl can't properly do it's job and errors accordingly. On Fri, Jan 29, 2016 at 3:08 PM, Slaven_Rezic via RT < bug-Object-InsideOut@rt.cpan.org> wrote: Show quoted text

> Queue: Object-InsideOut > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=106552 > > > On 2016-01-29 04:04:29, se456@rohan.id.au wrote:

> > Thankyou for taking the time earlier to read and respond to my bug > > report. > > I've finally had a chance to digest what you wrote and I just wanted > > to check > > I understood you correctly. > > > > You are correct that "." is in @INC, however I believe that > > Object::InsideOut > > is unusual for producing a fatal compile-time error when a non- > > readable > > directory is in @INC. This is the only CPAN module I have encountered > > that is > > sensitive about this. > > > > mkdir noread > > cd noread > > chmod 0 . > > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use Moose; package > > main; > > print "hello\n"' > > hello > > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use CGI; package > > main; > > print "hello\n"' > > hello > > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use XML::LibXML; > > package > > main; print "hello\n"' > > hello > > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use > > Object::InsideOut; > > package main; print "hello\n"' > > Can't locate OIO.pm: ./OIO.pm: Permission denied at > > /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line > > 99. > > ...propagated at > > /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line > > 108. > > BEGIN failed--compilation aborted at (eval 5) line 3. > > BEGIN failed--compilation aborted at > > /home/tdev/local/lib/perl5/Object/InsideOut/Exception.pm line 64. > > Compilation failed in require at > > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > > BEGIN failed--compilation aborted at > > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > > Compilation failed in require at -e line 1. > > BEGIN failed--compilation aborted at -e line 1. > > > > If you don't think this is a bug, then fine, but I personally find > > this > > behavior surprising. > > > > FYI, I use Object::InsideOut because it's a dependency for > > Math::Random::MT::Auto and running my script using cron is what led me > > to a > > situation where the current directory is unreadable. It was easily > > worked > > around, but took a while to diagnose.

> > I think this is a bug, but deeper, in base.pm. It can be easily > reproduced like this (after making the current directory unreadable): > > $ perl5.23.7 -e 'use base "Foo"' > Can't locate Foo.pm: ./Foo.pm: Permission denied at > /opt/perl-5.23.7/lib/site_perl/5.23.7/base.pm line 100. > ...propagated at /opt/perl-5.23.7/lib/site_perl/5.23.7/base.pm > line 109. > BEGIN failed--compilation aborted at -e line 1. > > > base.pm's code at this point: > > die if $@ && $@ !~ /^Can't locate \Q$fn\E .*? at .* line > [0-9]+(?:, <[^>]*> (?:line|chunk) [0-9]+)?\.\n\z/s > || $@ =~ /Compilation failed in require at .* > line [0-9]+(?:, <[^>]*> (?:line|chunk) [0-9]+)?\.\n\z/; > > So the first ":" in the error message is unexpected here. > > parent.pm seems to have the same problem. > >

Sat Jan 30 06:16:45 2016 SREZIC [...] cpan.org - Correspondence added

RT-Send-CC:

jdhedden [...] cpan.org

A super class may be available as a separate .pm and has to be required, or it could be defined inline in the running perl process. It's surprisingly hard (even impossible?) to reliably tell if the latter had happen, so base.pm (and parent.pm, unless -norequire option is used) tries to load the .pm anyway. But it does not fail if it's not there. An example: perl5.20.0 -e 'package NonExistent; sub something {} package SubClass; use base qw(NonExistent);' → No error, but if you look with strace or a perl debugger, then you see the load attempts: 16824 11:07:44.480611 stat("/opt/perl-5.20.0/lib/site_perl/5.20.0/x86_64-linux/NonExistent.pmc", 0x7ffc1f1f3ed0) = -1 ENOENT (No such file or directory) <0.000015> 16824 11:07:44.480676 stat("/opt/perl-5.20.0/lib/site_perl/5.20.0/x86_64-linux/NonExistent.pm", 0x7ffc1f1f3e10) = -1 ENOENT (No such file or directory) <0.000012> 16824 11:07:44.480734 stat("/opt/perl-5.20.0/lib/site_perl/5.20.0/NonExistent.pmc", 0x7ffc1f1f3ed0) = -1 ENOENT (No such file or directory) <0.000012> 16824 11:07:44.480787 stat("/opt/perl-5.20.0/lib/site_perl/5.20.0/NonExistent.pm", 0x7ffc1f1f3e10) = -1 ENOENT (No such file or directory) <0.000012> 16824 11:07:44.480842 stat("/opt/perl-5.20.0/lib/5.20.0/x86_64-linux/NonExistent.pmc", 0x7ffc1f1f3ed0) = -1 ENOENT (No such file or directory) <0.000013> 16824 11:07:44.480896 stat("/opt/perl-5.20.0/lib/5.20.0/x86_64-linux/NonExistent.pm", 0x7ffc1f1f3e10) = -1 ENOENT (No such file or directory) <0.000012> 16824 11:07:44.480951 stat("/opt/perl-5.20.0/lib/5.20.0/NonExistent.pmc", 0x7ffc1f1f3ed0) = -1 ENOENT (No such file or directory) <0.000012> 16824 11:07:44.481002 stat("/opt/perl-5.20.0/lib/5.20.0/NonExistent.pm", 0x7ffc1f1f3e10) = -1 ENOENT (No such file or directory) <0.000012> 16824 11:07:44.481054 stat("./NonExistent.pmc", 0x7ffc1f1f3ed0) = -1 ENOENT (No such file or directory) <0.000011> 16824 11:07:44.481100 stat("./NonExistent.pm", 0x7ffc1f1f3e10) = -1 ENOENT (No such file or directory) <0.000011> If the same cmdline is executed in the noread directory, then base.pm fails, even if the .pm is not needed at all. BTW, this seems to be a regression either in perl 5.20.0 or base.pm 2.22, because the failure is not there with perl 5.18.4 and base.pm 2.18 (or earlier versions). On 2016-01-29 15:17:01, JDHEDDEN wrote: Show quoted text

> I don't see this as a bug in base.pm. It stems from the 'require' > directive. >

> > echo 'package pkg; $VERSION = "1.00"; 1;' >pkg.pm > > perl -e 'require pkg' > > chmod 000 pkg.pm > > perl -e 'require pkg'

> Can't locate pkg.pm: ./pkg.pm: Permission denied at -e line 1. > > When permissions are not "correct" then perl can't properly do it's job and > errors accordingly. > > On Fri, Jan 29, 2016 at 3:08 PM, Slaven_Rezic via RT < > bug-Object-InsideOut@rt.cpan.org> wrote: >

> > Queue: Object-InsideOut > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=106552 > > > > > On 2016-01-29 04:04:29, se456@rohan.id.au wrote:

> > > Thankyou for taking the time earlier to read and respond to my bug > > > report. > > > I've finally had a chance to digest what you wrote and I just wanted > > > to check > > > I understood you correctly. > > > > > > You are correct that "." is in @INC, however I believe that > > > Object::InsideOut > > > is unusual for producing a fatal compile-time error when a non- > > > readable > > > directory is in @INC. This is the only CPAN module I have encountered > > > that is > > > sensitive about this. > > > > > > mkdir noread > > > cd noread > > > chmod 0 . > > > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use Moose; package > > > main; > > > print "hello\n"' > > > hello > > > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use CGI; package > > > main; > > > print "hello\n"' > > > hello > > > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use XML::LibXML; > > > package > > > main; print "hello\n"' > > > hello > > > perl -I/home/tdev/local/lib/perl5 -e 'package foo; use > > > Object::InsideOut; > > > package main; print "hello\n"' > > > Can't locate OIO.pm: ./OIO.pm: Permission denied at > > > /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line > > > 99. > > > ...propagated at > > > /home/rohan/perl5/perlbrew/perls/perl-5.22.0/lib/5.22.0/base.pm line > > > 108. > > > BEGIN failed--compilation aborted at (eval 5) line 3. > > > BEGIN failed--compilation aborted at > > > /home/tdev/local/lib/perl5/Object/InsideOut/Exception.pm line 64. > > > Compilation failed in require at > > > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > > > BEGIN failed--compilation aborted at > > > /home/tdev/local/lib/perl5/Object/InsideOut.pm line 11. > > > Compilation failed in require at -e line 1. > > > BEGIN failed--compilation aborted at -e line 1. > > > > > > If you don't think this is a bug, then fine, but I personally find > > > this > > > behavior surprising. > > > > > > FYI, I use Object::InsideOut because it's a dependency for > > > Math::Random::MT::Auto and running my script using cron is what led me > > > to a > > > situation where the current directory is unreadable. It was easily > > > worked > > > around, but took a while to diagnose.

> > > > I think this is a bug, but deeper, in base.pm. It can be easily > > reproduced like this (after making the current directory unreadable): > > > > $ perl5.23.7 -e 'use base "Foo"' > > Can't locate Foo.pm: ./Foo.pm: Permission denied at > > /opt/perl-5.23.7/lib/site_perl/5.23.7/base.pm line 100. > > ...propagated at /opt/perl-5.23.7/lib/site_perl/5.23.7/base.pm > > line 109. > > BEGIN failed--compilation aborted at -e line 1. > > > > > > base.pm's code at this point: > > > > die if $@ && $@ !~ /^Can't locate \Q$fn\E .*? at .* line > > [0-9]+(?:, <[^>]*> (?:line|chunk) [0-9]+)?\.\n\z/s > > || $@ =~ /Compilation failed in require at .* > > line [0-9]+(?:, <[^>]*> (?:line|chunk) [0-9]+)?\.\n\z/; > > > > So the first ":" in the error message is unexpected here. > > > > parent.pm seems to have the same problem. > > > >