The file name is illegal, but no, we won't return an error! yuck.

Is there a system call that can be called instead of C's stat?

The file name is illegal, but no, we won't return an error! yuck.

Not sure why "yuck"?

Either, it should be treated as illegal and return "The system cannot find the file specified",

or it is a valid alias for CWD and should do what it now does.

I can't see what other option there is?

Is there a system call that can be called instead of C's stat?

I'm not sure what that would achieve?

Most of the values returned by stat that actually have any meaning on NTFS, are available via GetFileAttributesEx().

But be aware, Win32.c:Win32_stat() already calls this (but only if _stat()/_stat64() fail??), along with several others (GetFileAttributesA()/GetVolumeInformationA()/GetFileInformationByHandle()) in order to fix-up what they see as bugs.

---

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?

Not sure why "yuck"?

Either, it should be treated as illegal and return "The system cannot find the file specified",

It's an invalid file name, so it should return an error indicating such. It doesn't, thus "yuck".

The filename, directory name, or volume label syntax is incorrect.
[download]

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?

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

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.

$ dir "\"\""
The network path was not found.

$ echo %ERRORLEVEL%
1
[download]

And when you search for the empty string, dir "", you get everything.

dir is not stat().

The quote " character is illegal in Windows filenames. Therefore, what you are passing to the OS is taken as the empty string.

No. If it would, stat() in the C example would return 0 (success), not -1 (error).

You are effectively asking, is there anything in the current directory. Which will always be true.

Wrong conclusion.

Alexander

Sorry, but you are wrong. Here is the proof:

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

int main( int argc, char **argv ) {
    struct _stat buf1, buf2;
    char *file = "\"\"";

    printf( "for %s; stat returned: %d\n", file, _stat( file, &buf1 ) 
+);

    printf(
        "gid: %d\natime:%I64x\nctime:%I64x\ndrive:%d\n"
        "inode:%d\nmode:%x\nmtime:%I64x\nnlink:%d\nrdev:%d\n"
        "size:%d\nuid:%d\n",
        buf1.st_gid, buf1.st_atime, buf1.st_ctime, buf1.st_dev,
        buf1.st_ino, buf1.st_mode, buf1.st_mtime, buf1.st_nlink, buf1.
+st_rdev,
        buf1.st_size, buf1.st_uid
    );

    printf( "\nFor %s; stat returned: %d\n", argv[1], _stat( argv[1], 
+&buf2 ) );

    printf(
        "gid: %d\natime:%I64x\nctime:%I64x\ndrive:%d\n"
        "inode:%d\nmode:%x\nmtime:%I64x\nnlink:%d\nrdev:%d\n"
        "size:%d\nuid:%d\n",
        buf2.st_gid, buf2.st_atime, buf2.st_ctime, buf2.st_dev,
        buf2.st_ino, buf2.st_mode, buf2.st_mtime, buf2.st_nlink, buf2.
+st_rdev,
        buf2.st_size, buf2.st_uid
    );
    return 1;
}
[download]

That code first stats the filename '""'; then it stats the pathname passed from the command line in argv1.

Run passing the path of the current directory, both sets of stats are identical:

C:\test>stat c:\test
for ""; stat returned: 0
gid: 0
atime:4ff203c6
ctime:49bba448
drive:2
inode:0
mode:41ff
mtime:4ff203c6
nlink:1
rdev:2
size:0
uid:0

For c:\test; stat returned: 0
gid: 0
atime:4ff203c6
ctime:49bba448
drive:2
inode:0
mode:41ff
mtime:4ff203c6
nlink:1
rdev:2
size:0
uid:0
[download]

Explain that in any way other than '""' is being taken to mean 'the current directory'?

---

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?

I don't know what combination of compiler and OS you use, but on my system (Win7 Ult + Strawberry 5.14.2 x64), your unmodified code clearly shows that stat() fails:

X:\>gcc -Wall --pedantic -o 979536.exe 979536.c
979536.c: In function 'main':
979536.c:18: warning: ISO C does not support the 'I64' ms_printf lengt
+h modifier
979536.c:18: warning: ISO C does not support the 'I64' ms_printf lengt
+h modifier
979536.c:18: warning: ISO C does not support the 'I64' ms_printf lengt
+h modifier
979536.c:18: warning: format '%d' expects type 'int', but argument 11 
+has type '_off_t'
979536.c:29: warning: ISO C does not support the 'I64' ms_printf lengt
+h modifier
979536.c:29: warning: ISO C does not support the 'I64' ms_printf lengt
+h modifier
979536.c:29: warning: ISO C does not support the 'I64' ms_printf lengt
+h modifier
979536.c:29: warning: format '%d' expects type 'int', but argument 11 
+has type '_off_t'

X:\>979536.exe
for ""; stat returned: -1
gid: 0
atime:0
ctime:0
drive:0
inode:0
mode:0
mtime:0
nlink:0
rdev:0
size:0
uid:0

For (null); stat returned: -1
gid: 0
atime:0
ctime:0
drive:0
inode:0
mode:0
mtime:0
nlink:0
rdev:0
size:0
uid:0

X:\>gcc --version
gcc (GCC) 4.4.7 20111023 (prerelease) [svn/rev.180339 - mingw-w64/oz]
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There i
+s NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PUR
+POSE.


X:\>
[download]

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)