Re^3: true from (-e "") on Windoze (" is an illegal filename character

As I showed in Re^3: true from (-e "") on Windoze (" is an illegal filename character, it is the MS CRT stat (and I believe the Winapi function(s) that underlies it), that chooses to treat a filename passed as '""' as meaning 'the current directory'.

As such, I don't think that it can be blamed on Perl.

That's not to say that Perl might not choose to prevent it by detecting it and failing, before passing it through to stat, and so regularise the cross-platform Perl behaviour.

But, it would be 'correcting' for a bug -- if you wish to call it that -- in the CRT, not Perl per se.

I also suspect that the 'bug' probably goes all the way back to MSDOS, where it was considered a useful behaviour.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re^3: true from (-e "") on Windoze (" is an illegal filename character Download Code

Replies are listed 'Best First'.
Re^4: true from (-e "") on Windoze (" is an illegal filename character by syphilis (Archbishop) on Jul 03, 2012 at 11:00 UTC
But, it would be 'correcting' for a bug ... in the CRT Yeah ... and I guess that if it were to be 'corrected' in perl (as I was recommending), there's always the chance that someone will object because we're no longer following Windows CRT behaviour. Maybe perl should warn about this whenever `$file =~ /^"/ && $file !~ /[^"]/ && $^O =~ /MSWin32/i` [download] (which, I think, are the pertinent conditions) but I don't think I'll take that up with the powers that be. Cheers, Rob	[reply] [d/l]
Re^5: true from (-e "") on Windoze (" is an illegal filename character by BrowserUk (Patriarch) on Jul 03, 2012 at 18:40 UTC
Maybe perl should warn about this The more I think about it, the less I like the idea of a warning for what is just platform specific behaviour. There's that "non-portable" warning about integers > 2**32 that pops up on 64-bit platforms; it just bugs me. I think the simplest solution is the best here: just add a note about it to the stat docs. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]
Re^4: true from (-e "") on Windoze (" is an illegal filename character by BillKSmith (Monsignor) on Jul 04, 2012 at 04:27 UTC
I agree that the 'problem' has nothing to do whith perl. It makes sense to consider double quotes around a windows filename as required if the filename contains whitespace and optional otherwise. From this view, the dir command followed by two double quotes should display the same thing as the dir command without them - the current directory. This logic requires other system functions to also treat the null file name as the current directory.	[reply]
Re^5: true from (-e "") on Windoze (" is an illegal filename character by afoken (Chancellor) on Jul 05, 2012 at 20:33 UTC
You are mixing command line parsing in command.com / cmd.exe and the Windows-APIs. Unlike in Unix, command line parsing is the job of the invoked program (and not that of the shell) on Windows, this typically happens in the C RTL. The command interpreters themself also parse their input, but only to find the executable or build-in command and to handle redirections. The build-in commands (dir, cd, ...) must also parse their argument string, probably using the same or very similar routines. After that parsing has happened, quotes and escape characters are gone, and the program or build-in command has a list of (unescaped) arguments, some of them are passed to API functions. The API functions do not remove quotes: X:\>dir 979536.exe Volume in drive X is RAMDISK Volume Serial Number is 065B-0000 Directory of X:\ 05.07.2012 22:04 121.535 979536.exe 1 File(s) 121.535 bytes 0 Dir(s) 129.867.776 bytes free X:\>dir "979536.exe" Volume in drive X is RAMDISK Volume Serial Number is 065B-0000 Directory of X:\ 05.07.2012 22:04 121.535 979536.exe 1 File(s) 121.535 bytes 0 Dir(s) 129.867.776 bytes free X:\>perl -Mautodie -e "open $f,'979536.exe'" X:\>perl -Mautodie -e "open $f,chr(34).'979536.exe'.chr(34)" Can't open($fh, '"979536.exe"'): Invalid argument at -e line 1 X:\>type openfail.c #include <stdio.h> #include <errno.h> int main(int argc, char ** argv) { FILE * f; if ((f=fopen("979536.exe","r"))==NULL) { perror("open without quotes"); } else { fclose(f); } if ((f=fopen("\"979536.exe\"","r"))==NULL) { perror("open with quotes"); } else { fclose(f); } return 0; } X:\>gcc -Wall -pedantic -o openfail.exe openfail.c X:\>.\openfail.exe open with quotes: Invalid argument X:\> [download] Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l]