Front page | perl.perl5.porters |
Postings from May 2015
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 >Thread Next