Tracking this stuff through the perl sources is a nightmare.

• The -f is mapped to a function Perl_pp_ftis in opcode.h (for FileTestIs (a file) perhaps?).
• Which is mapped to lib\core\embed.h:#define pp_ftis                        Perl_pp_ftis
• Which is implemented in terms of my_stat() in pp_sys.c

  PP(pp_ftis)
  {
      I32 result = my_stat();
      dSP;
      if (result < 0)
      RETPUSHUNDEF;
      RETPUSHYES;
  }
  [download]

• Which is mapped to embed.h:3209:#define my_stat()          Perl_my_stat(aTHX)
• Perl_my_stat() is implemented in doio.c in terms of PerlLIO_fstat()
• Which is mapped to iperlsys.h:734:#define PerlLIO_fstat(fd, buf)           Fstat((fd), (buf))
• Which gets mapped to lib\core\dosish.h:133:#define Fstat(fd,bufptr)   fstat((fd),(bufptr))
• Which is a c-runtime api.

  However, fstat() takes a file descriptor (fd), which implies an open file handle...Should have noticed that earlier. Track back to where the calls are not defined in terms of a file descriptor and were back at doio.c. Sure enough, follow the other path in Perl_my_stat()and we find it calls PerlLIO_stat()

• Which maps to lib\core\iperlsys.h:739:#define PerlLIO_stat(name, buf)         Stat((name), (buf))
• Which is mapped to dosish.h:142:#  define Stat(fname,bufptr) stat((fname),(bufptr))
• Then you have to move over to the C-runtime headers, which I don't have for MSVC++ (as used by Active State), so I can't bore you with those details, but suffice it to say, stat() ends up getting mapped to _stat64() as AS build with large file support which means they need the version of stat that can handle filesizes >32-bit.

Dissassembling the code in MSVCRT.dll:_stat64 we find this

The salient point here is the call to EXT:KERNEL32.DLL!FindFirstFileA.

You asked: ...why this is effectively performing a directory search in order to test one filename!..... And the answer goes something like this.

When you pass a filespec to stat() or one of its varients, in order to ask the os for information about the file, you need to get an OS 'handle' (an INODE) in unix terms) to that file. You can get one of these by various means, but if you aren't interested in opening the file, then the OS gives you a call to obtain that handle. In Win32 this is FindFirstFile(), I think the equivalent under unix is opendir or maybe it gets translated directly into (ioctl?) calls to the underlying filesystem.

Anyway, the point is that under normal circumstances, calling FFF with a non-wildcard filespec returns a structure containing (almost) all the information required to satisfy the stat() call.

Whilst you may not thinkof stat() as doing a "directory search", it has to have the filesystem search to find the information to fulfil the stat() call, which on unix is in the INODE and so a search is being done, it's just that the API name doesn't reflect this.

The fact that your filespec contains some adornments used for determining the filemode is a Perl thing and not the OS's problem.

That these conflict with an undocumented feature within the OS is ...erm.. unfortunate! I guess that LW and MS came to the same conclusion that '<' & '>' are good candidates for using as meta characters as most sane people are unlikely to embed these in their filenames as they would conflict with their use as redirection metacharacters by CLIs.

In the final analysis, you would have to strip Perls two-arg open metacharacters from the filespec before you passed them to stat(), whichever OS you are on!

Whew! :-)

BrowserUK++! Thank you so much for your in-depth analysis; this strange problem obviously piqued your curiosity even more-so than mine!

It just goes to show that you should never make assumptions about how things actually work when trying to write portable code.

Thanks again.

Cheers,

-- Dave :-)

---

$q=[split+qr,,,q,~swmi,.$,],+s.$.Em~w^,,.,s,.,$&&$$q[pos],eg,print