From @jmdh

Created by @jmdh

As reported in
<http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257568>
the behaviour of Cwd​::abs_path has changed over time to working with
non-existent to paths, to not.

Quoting Roger in that report (on Sun, 11 Jul 2010)​:

"To justify why I think this is a serious misfeature, let's look at
what we want to do. abs_path is doing two things​:
1) if the path is relative to the CWD, we make it absolute
2) if the path contains any symbolic links, we remove them

Now, if the path doesn't yet exist, by definition it doesn't
contain any links, so part 2 can be skipped. But making it
absolute is still useful. The path may also partially exist.
If I'm in /tmp/foo and call abs_path('bar') then it could
return /tmp/foo/bar if /tmp/foo contains no links. If foo
was a symlink to /srv/baz then it should return /srv/baz/bar.

To summarise​: abs_path can still work sanely in the existence
of a nonexistent (or partially existent) path. It can walk up
the tree so far as it can (while it exists) both making it
absolute and removing links as necessary and then it can
return the nonexistent part verbatim after that. For users
who want to get a canonicalised path, returning undef when
there's a perfectly reasonable answer to give them is not
good, and it would be great to get this long-standing
regression fixed.
"

Flags:
    category=library
    severity=low
    module=Cwd

Site configuration information for perl 5.17.10:

Configured by dom at Sun Mar 31 22:23:05 BST 2013.

Summary of my perl5 (revision 5 version 17 subversion 10) configuration:
   
  Platform:
    osname=linux, osvers=3.2.0-4-686-pae, archname=i686-linux
    uname='linux perltest2 3.2.0-4-686-pae #1 smp debian 3.2.32-1 i686 gnulinux '
    config_args='-de -Dprefix=/home/dom/perl5/perlbrew/perls/perl-5.17.10 -Dusedevel -Aeval:scriptdir=/home/dom/perl5/perlbrew/perls/perl-5.17.10/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.7.2', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib /usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.17.10:
    /home/dom/perl5/perlbrew/perls/perl-5.17.10/lib/site_perl/5.17.10/i686-linux
    /home/dom/perl5/perlbrew/perls/perl-5.17.10/lib/site_perl/5.17.10
    /home/dom/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10/i686-linux
    /home/dom/perl5/perlbrew/perls/perl-5.17.10/lib/5.17.10
    .


Environment for perl 5.17.10:
    HOME=/home/dom
    LANG=en_GB.UTF-8
    LANGUAGE=en_GB:en
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/dom/perl5/perlbrew/bin:/home/dom/perl5/perlbrew/perls/perl-5.17.10/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
    PERLBREW_BASHRC_VERSION=0.59
    PERLBREW_HOME=/home/dom/.perlbrew
    PERLBREW_MANPATH=/home/dom/perl5/perlbrew/perls/perl-5.17.10/man
    PERLBREW_PATH=/home/dom/perl5/perlbrew/bin:/home/dom/perl5/perlbrew/perls/perl-5.17.10/bin
    PERLBREW_PERL=perl-5.17.10
    PERLBREW_ROOT=/home/dom/perl5/perlbrew
    PERLBREW_VERSION=0.59
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @jkeenan

On Sun Mar 31 15​:05​:56 2013, dom wrote​:

This is a bug report for perl from dom@​earth.li,
generated with the help of perlbug 1.39 running under perl 5.17.10.

-----------------------------------------------------------------
[Please describe your issue here]

As reported in
<http​://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257568>
the behaviour of Cwd​::abs_path has changed over time to working with
non-existent to paths, to not.

Quoting Roger in that report (on Sun, 11 Jul 2010)​:

"To justify why I think this is a serious misfeature, let's look at
what we want to do. abs_path is doing two things​:
1) if the path is relative to the CWD, we make it absolute
2) if the path contains any symbolic links, we remove them

Now, if the path doesn't yet exist, by definition it doesn't
contain any links, so part 2 can be skipped. But making it
absolute is still useful. The path may also partially exist.
If I'm in /tmp/foo and call abs_path('bar') then it could
return /tmp/foo/bar if /tmp/foo contains no links. If foo
was a symlink to /srv/baz then it should return /srv/baz/bar.

To summarise​: abs_path can still work sanely in the existence
of a nonexistent (or partially existent) path. It can walk up
the tree so far as it can (while it exists) both making it
absolute and removing links as necessary and then it can
return the nonexistent part verbatim after that. For users
who want to get a canonicalised path, returning undef when
there's a perfectly reasonable answer to give them is not
good, and it would be great to get this long-standing
regression fixed.
"

I observe the following on Darwin (where /tmp is a symlink to /private/tmp)​:

#####
$ cd /tmp
$ perl -E 'use Cwd; say "<", Cwd​::abs_path(q{foo}), ">"'
</private/tmp/foo>
#####

#####
$ perl -E 'use Cwd; say "<", Cwd​::abs_path(q{foo/bar}), ">"'
<>
#####

... where neither 'foo' nor 'foo/bar' exists. It seems it is the
addition of another level in the filesystem that causes 'abs_path' to
return what I think is more likely an empty string rather than an
undefined value.

Comments?

Thank you very much.
Jim Keenan

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

From @jkeenan

This may be related to RT #116332​: "abs_path dies on Windows when
called with non-existent path".

From [Unknown Contact. See original ticket]

This may be related to RT #116332​: "abs_path dies on Windows when
called with non-existent path".