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
Comments
From rich@richelberger.comCreated by rich@richelberger.comPlease 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> In Linux / Mac, it results in an empty array since it is file not found. $VAR1 = 0; Perl Info
|
From @tonycozOn Sat May 02 11:30:43 2015, rich@richelberger.com wrote:
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/... Tony |
The RT System itself - Status changed from 'new' to 'open' |
From rich@richelberger.comThis 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.
|
From zefram@fysh.orgSince this is just platform behaviour that Perl is intentionally exposing, -zefram |
From @eserteDana Sat, 16 Dec 2017 00:15:50 -0800, zefram@fysh.org reče:
It's not only lstat() and stat() affected. Also file test operators give wrong results: perl -e "warn -e q{...}" perl -e "warn -d q{....}" perl -e "warn -r q{.......................}" The number of dots seems to be irrelevant (like already found out in the corresponding CPAN RT ticket). |
From @xsawyerxOn Sat, 16 Dec 2017 00:15:50 -0800, zefram@fysh.org wrote:
True. It's worthwhile adding it to perlport.pod though as something a developer might trip on. |
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
Migrated from rt.perl.org#124443 (status was 'open')
Searchable as RT124443$
The text was updated successfully, but these errors were encountered: