BrowserUK wrote:
Update: FWIW, this "undocumented feature" is deep within the OS, using '<' in the argument to FindFirstFile/FindNextFile apis also treats it the same way as '*'. It appears that this is the only undocumented character that exhibits this behaviour. Weirdness indeed.
Very strange indeed. As you say, none of the other Windows 'glob' or redirection characters exhibit this peculilar behaviour in this context.
open FILE, ">testfile.log" or die "Unable to create file: $!"; close FILE; if (! -f "*estfile.log") { print STDERR "Not a file *.\n"; } if (! -f "|testfile.log") { print STDERR "Not a file |.\n"; } if (! -f "?estfile.log") { print STDERR "Not a file ?.\n"; } if (! -f "<testfile.log") { print STDERR "Not a file <.\n"; } if (! -f ">>testfile.log") { print STDERR "Not a file >>.\n"; } exit; __END__ Not a file *. Not a file |. Not a file ?. Not a file >>.
What I don't understand is why this is effectively performing a directory search in order to test one filename! Does Windows not have the equivalent of the Unix stat() system call? The -f operator should just be calling the perl stat function. Does anyone with a better understanding of Win32 Perl than I understand what is happening here?
(Should I fall back to matching the filename with a regex?)
Cheers,
-- Dave :-)
$q=[split+qr,,,q,~swmi,.$,],+s.$.Em~w^,,.,s,.,$&&$$q[pos],eg,print
In reply to Re: Re: Re: Re: Unexpected file test (-f) result on Windows
by DaveH
in thread Unexpected file test (-f) result on Windows
by DaveH
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |