in reply to Re^2: true from (-e "") on Windoze (" is an illegal filename character
in thread true from (-e "") on Windoze

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?
  • Comment on Re^3: true from (-e "") on Windoze (" is an illegal filename character

Replies are listed 'Best First'.
Re^4: true from (-e "") on Windoze (" is an illegal filename character
by ikegami (Patriarch) on Sep 17, 2012 at 05:34 UTC

    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".

[reply]
      It's an invalid file name, so it should return an error indicating such.

      Not so.

      When you type "" on the command line, the program never sees the "s as they are processed by the command line processor. What the program receives is an empty string.

      In a very (perlish) pragmatic manner, the OS chooses to use what would otherwise be a nonsensical value -- to which even an error message of "Illegal filename" would be wrong, because strictly, they haven't supplied any file name -- to have a meta meaning and utilises it.

      In this case, it would be nonsensical to dir/stat files matching 'nothing', so it ascribes that value the meta meaning -- a default value -- of 'everything'.(*)

      That is no different to many perl built-ins using $_ if they receive no parameters. Or *nix taking a bare ls to mean everything. (The fact that they issue an "No such file or directory" message to ls '' is both strictly wrong; and missing a trick.)

      Pure pragmatism of the kind that Perl does so well.

      Whilst I could understand -- but disagree with -- a Java programmer saying yuck to such pragmatism, it strikes me as disjoint coming from a Perl aficionado like you.

      * It is even logical at the CS level, in that, the empty string is a vaild substring of every possible string.)

      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.

      RIP Neil Armstrong
[reply]
[d/l]
[select]
        I was talking about -e '""' (a system call), not dir "" (a command line tool). What's appropriate for one is not necessarily appropriate for the other.

        That said, I'm not convinced the behaviour of dir "" is the best. Note that ls "" returns ls: cannot access : No such file or directory.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom