Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Function lstat behavior case differs between Windows and Unix #14687

Closed
p5pRT opened this issue May 2, 2015 · 7 comments · Fixed by #21591
Closed

Function lstat behavior case differs between Windows and Unix #14687

p5pRT opened this issue May 2, 2015 · 7 comments · Fixed by #21591

Comments

@p5pRT
Copy link

p5pRT commented May 2, 2015

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

Searchable as RT124443$

@p5pRT
Copy link
Author

p5pRT commented May 2, 2015

From rich@richelberger.com

Created by rich@richelberger.com

Please refer to RT 90452 for background and original symptom. #NYCHackathon

In regular shells, the path expression ‘foo/…’ should fail and return an empty list.

<code>
use strict; use warnings; use 5.10.00;
mkdir a;
my @​result = lstat ‘a/…’;
say for @​result;
</code>

In Linux / Mac, it results in an empty array since it is file not found.
On Windows, the result is​:

$VAR1 = 0;
$VAR2 = 0;
$VAR3 = 16832;
$VAR4 = 0;
$VAR5 = 0;
$VAR6 = 0;
$VAR7 = 0;
$VAR8 = 0;
$VAR9 = 0;
$VAR10 = 0;
$VAR11 = 0;
$VAR12 = '';
$VAR13 = '';

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.20.2:

Configured by rich at Tue Feb 24 17:10:19 EST 2015.

Summary of my perl5 (revision 5 version 20 subversion 2) configuration:
   
  Platform:
    osname=darwin, osvers=14.1.0, archname=darwin-2level
    uname='darwin ananke 14.1.0 darwin kernel version 14.1.0: mon dec 22 23:10:38 pst 2014; root:xnu-2782.10.72~2release_x86_64 x86_64 '
    config_args='-de -Dprefix=/Users/rich/perl5/perlbrew/perls/perl-5.20.1 -Aeval:scriptdir=/Users/rich/perl5/perlbrew/perls/perl-5.20.1/bin'
    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-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include',
    optimize='-O3',
    cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /usr/lib
    libs=-ldbm -ldl -lm -lutil -lc
    perllibs=-ldl -lm -lutil -lc
    libc=, so=dylib, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'

Locally applied patches:
    Devel::PatchPerl 1.30


@INC for perl 5.20.2:
    /Users/rich/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.2/darwin-2level
    /Users/rich/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.2
    /Users/rich/perl5/perlbrew/perls/perl-5.20.1/lib/5.20.2/darwin-2level
    /Users/rich/perl5/perlbrew/perls/perl-5.20.1/lib/5.20.2
    /Users/rich/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1
    /Users/rich/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl
    .


Environment for perl 5.20.2:
    DYLD_LIBRARY_PATH (unset)
    HOME=/Users/rich
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/texlive/2014/bin/universal-darwin:/Users/rich/perl5/perlbrew/bin:/Users/rich/perl5/perlbrew/perls/perl-5.20.1/bin:/usr/local/git/bin:/opt/subversion/bin:/Users/rich/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/texbin
    PERLBREW_BASHRC_VERSION=0.72
    PERLBREW_HOME=/Users/rich/.perlbrew
    PERLBREW_MANPATH=/Users/rich/perl5/perlbrew/perls/perl-5.20.1/man
    PERLBREW_PATH=/Users/rich/perl5/perlbrew/bin:/Users/rich/perl5/perlbrew/perls/perl-5.20.1/bin
    PERLBREW_PERL=perl-5.20.1
    PERLBREW_ROOT=/Users/rich/perl5/perlbrew
    PERLBREW_VERSION=0.72
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented May 4, 2015

From @tonycoz

On Sat May 02 11​:30​:43 2015, rich@​richelberger.com wrote​:

Please refer to RT 90452 for background and original symptom.
#NYCHackathon

In regular shells, the path expression ‘foo/…’ should fail and return
an empty list.

<code>
use strict; use warnings; use 5.10.00;
mkdir a;
my @​result = lstat ‘a/…’;
say for @​result;
</code>

In Linux / Mac, it results in an empty array since it is file not
found.
On Windows, the result is​:

$VAR1 = 0;
$VAR2 = 0;
$VAR3 = 16832;
$VAR4 = 0;
$VAR5 = 0;
$VAR6 = 0;
$VAR7 = 0;
$VAR8 = 0;
$VAR9 = 0;
$VAR10 = 0;
$VAR11 = 0;
$VAR12 = '';
$VAR13 = '';

This looks like a bug in Windows, I tested

  .\miniperl -le "print for stat 'win32/...'"

under the debugger, the call​:

  DWORD r = GetFileAttributesA(path);

in win32_stat() is returning 16 rather than 0xFFFFFFFF indicating that win32/...
is a directory.

Tony

@p5pRT
Copy link
Author

p5pRT commented May 4, 2015

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

@p5pRT
Copy link
Author

p5pRT commented May 5, 2015

From rich@richelberger.com

This is an old DOS behavior that’s been around since time began for DOS. However, it’s behavior has been inconsistent over the years. It used to be “…” referenced “two directories up”. But, even going back to Windows 2003, it doesn’t do that anymore. I don’t have Win2k or Win95 around anymore, so I can’t check before then. I’m now thinking it’s not perl’s responsibility to account for it. But I don’t think it’s a Microsoft bug either.

I think it is just something the user needs to be aware of — and I will put it in the File​::Path documentation. The reason is the behavior on the command line is the same as what’s described in the originating File​::Path RT OP. Although I think being able to use ‘…’ is dangerous, that’s just an opinion and I don’t think it’s Perl’s job the protect the user in this case. Perl’s just doing what it was asked to do.

But I would like there to be consideration for putting this behavior in perlport.pod - I didn’t see anything there around this filesystem behavior.

On May 3, 2015, at 8​:36 PM, Tony Cook via RT <perlbug-followup@​perl.org> wrote​:

On Sat May 02 11​:30​:43 2015, rich@​richelberger.com wrote​:

Please refer to RT 90452 for background and original symptom.
#NYCHackathon

In regular shells, the path expression ‘foo/…’ should fail and return
an empty list.

<code>
use strict; use warnings; use 5.10.00;
mkdir a;
my @​result = lstat ‘a/…’;
say for @​result;
</code>

In Linux / Mac, it results in an empty array since it is file not
found.
On Windows, the result is​:

$VAR1 = 0;
$VAR2 = 0;
$VAR3 = 16832;
$VAR4 = 0;
$VAR5 = 0;
$VAR6 = 0;
$VAR7 = 0;
$VAR8 = 0;
$VAR9 = 0;
$VAR10 = 0;
$VAR11 = 0;
$VAR12 = '';
$VAR13 = '';

This looks like a bug in Windows, I tested

.\miniperl -le "print for stat 'win32/...'"

under the debugger, the call​:

DWORD r = GetFileAttributesA(path);

in win32_stat() is returning 16 rather than 0xFFFFFFFF indicating that win32/...
is a directory.

Tony

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2017

From zefram@fysh.org

Since this is just platform behaviour that Perl is intentionally exposing,
this ticket should be closed.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2017

From @eserte

Dana Sat, 16 Dec 2017 00​:15​:50 -0800, zefram@​fysh.org reče​:

Since this is just platform behaviour that Perl is intentionally exposing,
this ticket should be closed.

It's not only lstat() and stat() affected. Also file test operators give wrong results​:

perl -e "warn -e q{...}"
1 at -e line 1.

perl -e "warn -d q{....}"
1 at -e line 1.

perl -e "warn -r q{.......................}"
1 at -e line 1.

The number of dots seems to be irrelevant (like already found out in the corresponding CPAN RT ticket).

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2017

From @xsawyerx

On Sat, 16 Dec 2017 00​:15​:50 -0800, zefram@​fysh.org wrote​:

Since this is just platform behaviour that Perl is intentionally exposing,
this ticket should be closed.

True.

It's worthwhile adding it to perlport.pod though as something a developer might trip on.

@tonycoz tonycoz self-assigned this Oct 11, 2020
genio added a commit to genio/perl5 that referenced this issue Oct 15, 2020
As discussed on the mailing list here:
https://www.nntp.perl.org/group/perl.perl5.porters/2020/10/msg258453.html

This just removes the declaration that we support the very old versions
of Windows that have long since been EOLed.

For reference of problems related to maintaining the EOLed versions:
Perl#4145
Perl#6080
Perl#7410
Perl#8502
Perl#9025
Perl#12431
Perl#14687
@xenu xenu removed the affects-5.20 label Nov 19, 2021
tonycoz added a commit to tonycoz/perl5 that referenced this issue Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants