Wrong results from Cwd::abspath and Cwd::fast_abs_path #14887

p5pRT · 2015-09-03T14:44:07Z

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

Searchable as RT125979$

p5pRT · 2015-09-03T14:44:07Z

From jrw32982@yahoo.com

Created by jrw32982@yahoo.com

This bug affects both Cwd::abs_path (on cygwin) and Cwd::fast_abs_path (on
linux). The bug is present since at least perl 5.8.8.

Assuming /MYFILE exists (for some file) and is a file and pwd is /, then:

cygwin $ cd /
cygwin $ ls -l ./Cygwin.ico
-rw-r----- 1 jrw32982 JRW 157097 Jan 9 2015 ./Cygwin.ico
cygwin $ perl -wle 'use Cwd; print Cwd::abs_path "./Cygwin.ico"'
//Cygwin.ico
cygwin $ perl -v
This is perl 5, version 14...

linux $ cd /
linux $ ls -l ./.autofsck
-rw-r--r-- 1 root root 0 May 29 13:33 ./.autofsck
linux $ perl -wle ' use Cwd; print Cwd::fast_abs_path "./.autofsck"'
//.autofsck
linux $ perl -v
This is perl 5, version 22...

The outputs are wrong since they start with // instead of /. This is
especially bad on cygwin where trying to use the output starting with //
results in an attempted network search for a server called Cygwin.ico.

Perl Info


Flags:
    category=library
    severity=medium
    module=Cwd

Site configuration information for perl 5.22.0:

Configured by jrw32982 at Wed Sep  2 14:40:19 EDT 2015.

Summary of my perl5 (revision 5 version 22 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=2.6.18-274.el5, archname=x86_64-linux
    uname='linux trvlapp0305 2.6.18-274.el5 #1 smp fri jul 8 17:36:59 edt 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Dprefix=/home/jrw32982/perl'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=define, use64bitall=define, 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 -D_FORTIFY_SOURCE=2',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-51)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib /lib64 /usr/lib64 /usr/local/lib64
    libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.5'
  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'



@INC for perl 5.22.0:
    /home/jrw32982/std/lib/perl
    /home/jrw32982/perl/lib/site_perl/5.22.0/x86_64-linux
    /home/jrw32982/perl/lib/site_perl/5.22.0
    /home/jrw32982/perl/lib/5.22.0/x86_64-linux
    /home/jrw32982/perl/lib/5.22.0
    .


Environment for perl 5.22.0:
    HOME=/home/jrw32982
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_ALL=C
    LD_LIBRARY_PATH=/etc/emc/rsa/cst/lib
    LOGDIR (unset)
    PATH=/home/jrw32982/vim73/bin:/home/jrw32982/std/bin:/home/jrw32982/sh:/usr/local/sbin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/usr/X11R6/bin:/etc:.:/medstat/devl/tools/common/scripts:/medstat/devl/tools/Linux_5.7/bin
    PERL5LIB=/home/jrw32982/std/lib/perl
    PERL_BADLANG (unset)
    SHELL=/bin/ksh

p5pRT · 2015-09-07T16:53:08Z

From @ikegami

On Thu, Sep 3, 2015 at 10:44 AM, John Wiersba <perlbug-followup@perl.org>
wrote:

The outputs are wrong since they start with // instead of /. This is
especially bad on cygwin where trying to use the output starting with //
results in an attempted network search for a server called Cygwin.ico.

No, they aren't wrong for non-cygwin unix systems.

$ ls -ld /home
drwxr-x--x 1266 root root 45056 Sep 6 09:29 /home

$ ls -ld //home
drwxr-x--x 1266 root root 45056 Sep 6 09:29 //home

They're just not canonical. But they are indeed wrong for Cygwin.

$ ls -ld /home
drwxrwxrwt+ 1 ikegami root 0 Apr 3 2011 /home

$ ls -ld //home
ls: cannot access //home: No such file or directory

p5pRT · 2015-09-07T16:53:08Z

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

p5pRT · 2015-09-07T17:04:28Z

From @ilmari

Eric Brine <ikegami@adaelis.com> writes:

On Thu, Sep 3, 2015 at 10:44 AM, John Wiersba <perlbug-followup@perl.org>
wrote:

The outputs are wrong since they start with // instead of /. This is
especially bad on cygwin where trying to use the output starting with //
results in an attempted network search for a server called Cygwin.ico.

No, they aren't wrong for non-cygwin unix systems.

$ ls -ld /home
drwxr-x--x 1266 root root 45056 Sep 6 09:29 /home

$ ls -ld //home
drwxr-x--x 1266 root root 45056 Sep 6 09:29 //home

This may be the case on your system, but POSIX allows implementations to
handle // specially:

If a pathname begins with two successive <slash> characters, the
first component following the leading <slash> characters may be
interpreted in an implementation-defined manner

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12

They're just not canonical. But they are indeed wrong for Cygwin.

And AFAIK for QNX as well, which takes advantage of the above POSIX
provision.

--
"I use RMS as a guide in the same way that a boat captain would use
a lighthouse. It's good to know where it is, but you generally
don't want to find yourself in the same spot." - Tollef Fog Heen

p5pRT · 2015-09-07T17:24:30Z

From jrw32982@yahoo.com

Hi, Eric. I believe they are also wrong for unix/linux. i'm familiar with the semantics of a leading // on unix/linux. But the purpose of these functions is to canonicalize the path by, for example, removing symlinks, and "." and ".." components, which they do for every other input. They also replace //+ with /.

From http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html

If there are multiple pathnames that getcwd() could place in the array pointed to by buf, one beginning with asingle <slash> character and one or more beginning with two <slash> characters, then getcwd() shall place thepathname beginning with a single <slash> character in the array.
-- John

From: Eric Brine via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Monday, September 7, 2015 12:53 PM
Subject: Re: [perl #125979] Wrong results from Cwd::abspath and Cwd::fast_abs_path

On Thu, Sep 3, 2015 at 10:44 AM, John Wiersba <perlbug-followup@perl.org>
wrote:

The outputs are wrong since they start with // instead of /. This is
especially bad on cygwin where trying to use the output starting with //
results in an attempted network search for a server called Cygwin.ico.

No, they aren't wrong for non-cygwin unix systems.

$ ls -ld /home
drwxr-x--x 1266 root root 45056 Sep 6 09:29 /home

$ ls -ld //home
drwxr-x--x 1266 root root 45056 Sep 6 09:29 //home

They're just not canonical. But they are indeed wrong for Cygwin.

$ ls -ld /home
drwxrwxrwt+ 1 ikegami root 0 Apr 3 2011 /home

$ ls -ld //home
ls: cannot access //home: No such file or directory

p5pRT · 2017-06-09T20:52:42Z

From jrw32982@yahoo.com

Created by jrw32982@yahoo.com

# on Linux:
$ sudo touch /abc
$ cd /
$ perl -MCwd=fast_abs_path -le 'print fast_abs_path "./abc"'
//abc
# should be: /abc

# on Cygwin:
$ touch /abc
$ cd /
$ perl -MCwd=abs_path -le 'print abs_path "./abc"'
//abc
# should be: /abc

This has existed for many releases for both Cygwin and Linux (and perhaps
others). I have just confirmed it for RedHat 6.7/perl5.26. My version of
cygwin is older, so I haven't confirmed it on the most up-to-date cygwin.

Perl Info


Flags:
    category=library
    severity=medium
    module=Cwd

Site configuration information for perl 5.26.0:

Configured by jrw32982 at Wed May 31 16:38:10 EDT 2017.

Summary of my perl5 (revision 5 version 26 subversion 0) configuration:
   
  Platform:
    osname=linux
    osvers=2.6.32-573.el6.x86_64
    archname=x86_64-linux
    uname='linux trvlapp0352 2.6.32-573.el6.x86_64 #1 smp wed jul 1 18:23:37 edt 2015 x86_64 x86_64 x86_64 gnulinux '
    config_args='-Dprefix=/opt/perl5.26.0 -de'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
    optimize='-O2'
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion=''
    gccversion='4.4.7 20120313 (Red Hat 4.4.7-16)'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib /lib64 /usr/lib64 /usr/local/lib64
    libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.12.so
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version='2.12'
  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'



@INC for perl 5.26.0:
    /home/jrw32982/std/lib/perl
    /opt/perl5.26.0/lib/site_perl/5.26.0/x86_64-linux
    /opt/perl5.26.0/lib/site_perl/5.26.0
    /opt/perl5.26.0/lib/5.26.0/x86_64-linux
    /opt/perl5.26.0/lib/5.26.0


Environment for perl 5.26.0:
    HOME=/home/jrw32982
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_ALL=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/jrw32982/std/bin:/home/jrw32982/bin:/usr/local/sbin:/usr/local/bin:/bin:/usr/bin:/sbin:/usr/sbin:/etc:.
    PERL5LIB=/home/jrw32982/std/lib/perl
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2017-06-09T23:38:44Z

From @jkeenan

On Fri, 09 Jun 2017 20:52:42 GMT, jrw32982@yahoo.com wrote:

This is a bug report for perl from jrw32982@yahoo.com,
generated with the help of perlbug 1.40 running under perl 5.26.0.

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

# on Linux:
$ sudo touch /abc
$ cd /
$ perl -MCwd=fast_abs_path -le 'print fast_abs_path "./abc"'
//abc
# should be: /abc

# on Cygwin:
$ touch /abc
$ cd /
$ perl -MCwd=abs_path -le 'print abs_path "./abc"'
//abc
# should be: /abc

This has existed for many releases for both Cygwin and Linux (and
perhaps
others). I have just confirmed it for RedHat 6.7/perl5.26. My
version of
cygwin is older, so I haven't confirmed it on the most up-to-date
cygwin.

Is this the same problem you reported in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=125979 ?

Thank you very much.

--
James E Keenan (jkeenan@cpan.org)

p5pRT · 2017-06-09T23:38:44Z

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

p5pRT · 2017-06-10T03:00:48Z

From jrw32982@yahoo.com

You are right, I had forgotten that I had reported it then. It's the same issue and it appears it's still present in perl 5.26. I reported it again because I was just writing a module where I use abs_path() and I have to have code to handle the bug:
   ...
   $canonical_path = Cwd::abs_path $orig_path;
   return "unable to determine absolute path for $orig_path: $!"
      if !defined $canonical_path;
   $canonical_path =~ s{^//}{/};         # abs_path bug (cygwin, cwd=/, arg=./FILE)

-- John

From: James E Keenan via RT <perlbug-followup@perl.org>
To: jrw32982@yahoo.com
Sent: Friday, June 9, 2017 7:38 PM
Subject: [perl #131549] Cwd::abs_path/fast_abs_path returns non-canonical value (Linux/Cygwin)

On Fri, 09 Jun 2017 20:52:42 GMT, jrw32982@yahoo.com wrote:

This is a bug report for perl from jrw32982@yahoo.com,
generated with the help of perlbug 1.40 running under perl 5.26.0.

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

# on Linux:
$ sudo touch /abc
$ cd /
$ perl -MCwd=fast_abs_path -le 'print fast_abs_path "./abc"'
//abc
# should be: /abc

# on Cygwin:
$ touch /abc
$ cd /
$ perl -MCwd=abs_path -le 'print abs_path "./abc"'
//abc
# should be: /abc

This has existed for many releases for both Cygwin and Linux (and
perhaps
others). I have just confirmed it for RedHat 6.7/perl5.26. My
version of
cygwin is older, so I haven't confirmed it on the most up-to-date
cygwin.

Is this the same problem you reported in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=125979 ?

Thank you very much.

--
James E Keenan (jkeenan@cpan.org)

p5pRT added Severity Medium distro-Linux type-library labels Oct 19, 2019

jkeenan mentioned this issue Dec 17, 2019

Cwd.pm fast_abs_path is sometimes inconsistent and wrong #17369

Open

xenu removed the affects-5.22 label Nov 19, 2021

xenu removed the Severity Medium label Dec 15, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wrong results from Cwd::abspath and Cwd::fast_abs_path #14887

Wrong results from Cwd::abspath and Cwd::fast_abs_path #14887

p5pRT commented Sep 3, 2015

p5pRT commented Sep 3, 2015

p5pRT commented Sep 7, 2015

p5pRT commented Sep 7, 2015

p5pRT commented Sep 7, 2015

p5pRT commented Sep 7, 2015

p5pRT commented Jun 9, 2017

p5pRT commented Jun 9, 2017

p5pRT commented Jun 9, 2017

p5pRT commented Jun 10, 2017

Wrong results from Cwd::abspath and Cwd::fast_abs_path #14887

Wrong results from Cwd::abspath and Cwd::fast_abs_path #14887

Comments

p5pRT commented Sep 3, 2015

p5pRT commented Sep 3, 2015

From jrw32982@yahoo.com

Created by jrw32982@yahoo.com

p5pRT commented Sep 7, 2015

From @ikegami

p5pRT commented Sep 7, 2015

p5pRT commented Sep 7, 2015

From @ilmari

p5pRT commented Sep 7, 2015

From jrw32982@yahoo.com

p5pRT commented Jun 9, 2017

From jrw32982@yahoo.com

Created by jrw32982@yahoo.com

p5pRT commented Jun 9, 2017

From @jkeenan

p5pRT commented Jun 9, 2017

p5pRT commented Jun 10, 2017

From jrw32982@yahoo.com