Skip Menu |
Report information
Id: 131100
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: andreas.koenig.7os6VVqR [at] franz.ak.mind.de
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: 5.25.12



From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Subject: The "../" relative path misbehaving with regard to default_inc_excludes_dot
To: perlbug [...] perl.org
Date: Tue, 04 Apr 2017 22:03:54 +0200
Download (untitled) / with headers
text/plain 580b
"../foo" seems not to be regarded as a relative path, leading to this bug: perl -e ' use File::Temp qw(tempdir); my $tmpdir = tempdir("tXXXX", CLEANUP => 1); chdir $tmpdir; open my $fh, ">", "do_this.pl"; print $fh qq{print "not ok # executed from within ../$tmpdir/do_this.pl\\n";\n}; close $fh; do "../$tmpdir/do_this.pl"; ' not ok # executed from within ../ty2En/do_this.pl Expected behaviour would be to see a warning like do "../ty2En/do_this.pl" failed, '.' is no longer in @INC; did you mean do "./../ty2En/do_this.pl"? at -e line 8. -- andreas
Date: Wed, 5 Apr 2017 08:31:30 +0100
To: perl5-porters [...] perl.org
Subject: Re: [perl #131100] The "../" relative path misbehaving with regard to default_inc_excludes_dot
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 1.4k
On Tue, Apr 04, 2017 at 01:04:36PM -0700, Andreas J. Koenig via RT wrote: Show quoted text
> "../foo" seems not to be regarded as a relative path, leading to this bug: > > perl -e ' > use File::Temp qw(tempdir); > my $tmpdir = tempdir("tXXXX", CLEANUP => 1); > chdir $tmpdir; > open my $fh, ">", "do_this.pl"; > print $fh qq{print "not ok # executed from within ../$tmpdir/do_this.pl\\n";\n}; > close $fh; > do "../$tmpdir/do_this.pl"; > ' > not ok # executed from within ../ty2En/do_this.pl > > > Expected behaviour would be to see a warning like > > do "../ty2En/do_this.pl" failed, '.' is no longer in @INC; did you mean do "./../ty2En/do_this.pl"? at -e line 8.
This has been the behaviour of do (and require) since at least 5.6.1: $ pwd /home/davem/tmp/x $ cat foo.pl 1; $ cat ~/tmp/p #!perl # @INC=(); for ("", "./", "../x/") { my $f = "${_}foo.pl"; my $ok = (do $f) ? "ok" : "not ok"; printf "%12s %s\n", $f, $ok; } $ perl561o ~/tmp/p foo.pl not ok ./foo.pl ok ../x/foo.pl ok $ perl52511 ~/tmp/p do "foo.pl" failed, '.' is no longer in @INC at /home/davem/tmp/p line 6. foo.pl not ok ./foo.pl ok ../x/foo.pl ok I expect this behaviour is intentional (although to 'do' pod entry is silent on the matter). Should we change the behaviour now? -- You live and learn (although usually you just live).
CC: Perl5 Porters <perl5-porters [...] perl.org>
Date: Wed, 5 Apr 2017 10:59:15 +0200
To: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #131100] The "../" relative path misbehaving with regard to default_inc_excludes_dot
From: Graham Knop <haarg [...] haarg.org>
Download (untitled) / with headers
text/plain 1.6k
On Wed, Apr 5, 2017 at 9:31 AM, Dave Mitchell <davem@iabyn.com> wrote: Show quoted text
> On Tue, Apr 04, 2017 at 01:04:36PM -0700, Andreas J. Koenig via RT wrote:
>> "../foo" seems not to be regarded as a relative path, leading to this bug: >> >> perl -e ' >> use File::Temp qw(tempdir); >> my $tmpdir = tempdir("tXXXX", CLEANUP => 1); >> chdir $tmpdir; >> open my $fh, ">", "do_this.pl"; >> print $fh qq{print "not ok # executed from within ../$tmpdir/do_this.pl\\n";\n}; >> close $fh; >> do "../$tmpdir/do_this.pl"; >> ' >> not ok # executed from within ../ty2En/do_this.pl >> >> >> Expected behaviour would be to see a warning like >> >> do "../ty2En/do_this.pl" failed, '.' is no longer in @INC; did you mean do "./../ty2En/do_this.pl"? at -e line 8.
> > This has been the behaviour of do (and require) since at least 5.6.1: > > $ pwd > /home/davem/tmp/x > > $ cat foo.pl > 1; > > $ cat ~/tmp/p > #!perl > # > @INC=(); > for ("", "./", "../x/") { > my $f = "${_}foo.pl"; > my $ok = (do $f) ? "ok" : "not ok"; > printf "%12s %s\n", $f, $ok; > } > > $ perl561o ~/tmp/p > foo.pl not ok > ./foo.pl ok > ../x/foo.pl ok > > $ perl52511 ~/tmp/p > do "foo.pl" failed, '.' is no longer in @INC at /home/davem/tmp/p line 6. > foo.pl not ok > ./foo.pl ok > ../x/foo.pl ok > > I expect this behaviour is intentional (although to 'do' pod entry is > silent on the matter). Should we change the behaviour now?
It is definitely intentional behavior. Both do and require have a special case for paths starting with './' or '../'. The do documentation mentions './' now, but the other cases aren't documented at all.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Wed, 05 Apr 2017 02:03:33 -0700, haarg wrote: Show quoted text
> On Wed, Apr 5, 2017 at 9:31 AM, Dave Mitchell <davem@iabyn.com> wrote:
> > On Tue, Apr 04, 2017 at 01:04:36PM -0700, Andreas J. Koenig via RT > > wrote:
> >> "../foo" seems not to be regarded as a relative path, leading to > >> this bug: > >> > >> perl -e ' > >> use File::Temp qw(tempdir); > >> my $tmpdir = tempdir("tXXXX", CLEANUP => 1); > >> chdir $tmpdir; > >> open my $fh, ">", "do_this.pl"; > >> print $fh qq{print "not ok # executed from within > >> ../$tmpdir/do_this.pl\\n";\n}; > >> close $fh; > >> do "../$tmpdir/do_this.pl"; > >> ' > >> not ok # executed from within ../ty2En/do_this.pl > >> > >> > >> Expected behaviour would be to see a warning like > >> > >> do "../ty2En/do_this.pl" failed, '.' is no longer in @INC; did you > >> mean do "./../ty2En/do_this.pl"? at -e line 8.
> > > > This has been the behaviour of do (and require) since at least 5.6.1: > > > > $ pwd > > /home/davem/tmp/x > > > > $ cat foo.pl > > 1; > > > > $ cat ~/tmp/p > > #!perl > > # > > @INC=(); > > for ("", "./", "../x/") { > > my $f = "${_}foo.pl"; > > my $ok = (do $f) ? "ok" : "not ok"; > > printf "%12s %s\n", $f, $ok; > > } > > > > $ perl561o ~/tmp/p > > foo.pl not ok > > ./foo.pl ok > > ../x/foo.pl ok > > > > $ perl52511 ~/tmp/p > > do "foo.pl" failed, '.' is no longer in @INC at /home/davem/tmp/p > > line 6. > > foo.pl not ok > > ./foo.pl ok > > ../x/foo.pl ok > > > > I expect this behaviour is intentional (although to 'do' pod entry is > > silent on the matter). Should we change the behaviour now?
> > It is definitely intentional behavior. Both do and require have a > special case for paths starting with './' or '../'. The do > documentation mentions './' now, but the other cases aren't documented > at all.
This should be documented, as it apparently has confused some people. -- Karl Williamson
To: Karl Williamson via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #131100] The "../" relative path misbehaving with regard to default_inc_excludes_dot
From: Dave Mitchell <davem [...] iabyn.com>
CC: perl5-porters [...] perl.org
Date: Thu, 13 Apr 2017 10:37:09 +0100
Download (untitled) / with headers
text/plain 2.6k
On Sat, Apr 08, 2017 at 10:19:06AM -0700, Karl Williamson via RT wrote: Show quoted text
> On Wed, 05 Apr 2017 02:03:33 -0700, haarg wrote:
> > It is definitely intentional behavior. Both do and require have a > > special case for paths starting with './' or '../'. The do > > documentation mentions './' now, but the other cases aren't documented > > at all.
> > This should be documented, as it apparently has confused some people.
Now done: commit cfe4f7b628c08bfdd986ec52e1ff99241d5047a3 Author: David Mitchell <davem@iabyn.com> AuthorDate: Mon Apr 10 12:43:02 2017 +0100 Commit: David Mitchell <davem@iabyn.com> CommitDate: Thu Apr 13 09:58:00 2017 +0100 more tweaks to 'do's pod Make it clear that both ./ and ../ are special-cased. Affected files ... M pod/perlfunc.pod Differences ... diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod index c8140d5..38747a6 100644 --- a/pod/perlfunc.pod +++ b/pod/perlfunc.pod @@ -1807,11 +1807,14 @@ X<do> Uses the value of EXPR as a filename and executes the contents of the file as a Perl script: - do './stat.pl'; # file located relative to the current dir - do '/foo/stat.pl'; # file located at the specified absolute path + # load the exact specified file (./ and ../ special-cased) + do '/foo/stat.pl'; + do './stat.pl'; + do '../foo/stat.pl'; - do 'stat.pl'; # file searched for within @INC - do 'foo/stat.pl'; # file searched for within @INC + # search for the named file within @INC + do 'stat.pl'; + do 'foo/stat.pl'; C<do './stat.pl'> is largely like @@ -1824,9 +1827,9 @@ scope; C<eval STRING> does. It's the same, however, in that it does reparse the file every time you call it, so you probably don't want to do this inside a loop. -Using C<do> with no path, like +Using C<do> with a relative path (except for F<./> and F<../>), like - do 'stat.pl'; + do 'foo/stat.pl'; will search the L<C<@INC>|perlvar/@INC> directories, and update L<C<%INC>|perlvar/%INC> if the file is found. See L<perlvar/@INC> @@ -1855,7 +1858,8 @@ if there's a problem. You might like to use L<C<do>|/do EXPR> to read in a program configuration file. Manual error checking can be done this way: - # read in config files: system first, then user + # Read in config files: system first, then user. + # Beware of using relative pathnames here. for $file ("/share/prog/defaults.rc", "$ENV{HOME}/.someprogrc") { -- A power surge on the Bridge is rapidly and correctly diagnosed as a faulty capacitor by the highly-trained and competent engineering staff. -- Things That Never Happen in "Star Trek" #9


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org