Looks as if not the CMD.EXE internal command "ECHO" is executed, but an executable called echo.exe

Indeed, thanks.

It seems that system goes off searching the path for an executable with the name "echo.exe" instead of invoking the shell built in, and happens to find one that does wildcard expansion.

I always though that if you supplied a single string argument system invoked the shell and allowed it to perform the command resolution--which would mean that it would invoke the shell built-in in preference to searching the path.

It turns out that (on windows) it only does that if it "detects shell meta chars"--which it seems does not include * or \ or ^, as I would have assumed. Only '<', '>', '|' and '%'. Not even '&' or '&&' or '||' etc. Some attempt at *nix compatibility I think.

It turns out that (on windows) it only does that if it "detects shell meta chars"

From system:

If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient.

Hence, nothing Windows-specific going on in this respect (except that the set of metacharacters differs between Windows and *nix).
-- 
Ronald Fischer <ynnor@mm.st>

Hm. Even that's not the full sp. My single most frequent use of system is to load images I've just created into my graphics viewer; or html into my browser:

perl -e"system '1-centre.png'"  ## loads the image in my default image
+ viewer

# or

perl -e"system 'gened.html'"    ## loads the html into my default brow
+ser
[download]

They are both single scalar arguments, but are passed to the shell which then works out which executable to run.

Winding my way through the sources, the process (on win32) appears to be something like (abbreviated):

If it's a single scalar arg,

( if the first word has an '.exe' extension (and not path?); or if it doesn't have any extension nor just a '.', then try adding '.exe' )

then try searching the path to locate it.

If you find it, run it directly.

If it fails to find it, throw it at the shell and see if it can handle it.

If it has a dot, or any other extension, then just throw it at the shell and let it sort it out.

If any attempt to run it directly fails, throw it at the shell and give it a chance.

I think.

There are also various issues surrounding [sic] the issue of what consitutues the "first word" in the presence of a quoted, space containing first argument, but my brain won't let me build a clear picture of what actually happens, as the code is spit across several subroutines.

---

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 an inspiration; A true Folk's Guy

If it was Unix, I would try system 'which echo' to determine which binary was being run. Is there a Windows equiv?

I think there is, but there's also a perl equiv:

perl -MFile::Which -le 'print "$_: ", which $_ for @ARGV' echo
[download]

Of course, I'm assuming you have File::Which installed :-)

If it was Unix, I would...

If it was Unix, I would run strace/truss/tusc, and I would know within seconds what exactly is being called with which parameters. But heh, this isn't...

s-(?<=tusc)-/procmon-; s/If it was Unix, //

- tye