From @andk

"../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

From @iabyn

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?

--
You live and learn (although usually you just live).

The RT System itself - Status changed from 'new' to 'open'

From @haarg

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.

From @khwilliamson

On Wed, 05 Apr 2017 02​:03​:33 -0700, haarg wrote​:

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

From @iabyn

On Sat, Apr 08, 2017 at 10​:19​:06AM -0700, Karl Williamson via RT wrote​:

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 cfe4f7b
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

@iabyn - Status changed from 'open' to 'resolved'