Cwd::abs_path returns undef for non-existent paths

[p5pRT]

Migrated from rt.perl.org#117423 (status was 'open')

Searchable as RT117423$

[p5pRT]

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

Perl Info

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

[p5pRT]

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

[p5pRT]

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

[p5pRT]

From @jkeenan

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

[p5pRT]

From [Unknown Contact. See original ticket]

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