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.

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

Fortunately, they are. Imagine what would happen if Perl would bypass the shell. It would then try to execute gened.html or 1-centre.png, which would fail, because these files are not executable programs. The shell also "knows" about this weird Windows feature called "file associations" and implicitly invokes the "start" utility to start the appropriate application for you.
-- 
Ronald Fischer <ynnor@mm.st>

Fortunately, they are. Imagine what would happen if Perl would bypass the shell.

My point was that they are both single scalars, sans meta-characters, but still get passed to the shell. Hence contradicting your quote from the docs.

Personally, I wish Perl would simply pass single scalars directly to the shell and let it work out what happens. That way, the disconnect between what happened in my OP, where typing the command manually gave a different resolution to when I passed the command to system would not happen.

Beside which, the justification for attempting to bypass the shell: "If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient." doesn't make much sense.

The time perl spends trying a cock-eyed path resolution--and ends up not just bypassing shell built-ins, but also bypassing the pathext mechanism; which, for example, means that (using the standard setting), Perl will invoke an .exe in preference to a .com of the same name, as would be invoked by the shell--is no quicker than, and only slightly more memory efficient than just passing the argument directly to the shell.

It also means that the common practice of writing Perl script with the same name as executables, to enhance their function; and using set pathext=.pl;com;.exe;.bat;.cmd; to ensure they are invoked in preference to executables of the same name, is also bypassed.

As is the standard Windows practice of looking in the current directory for executables before chasing the path.

But I guess that's another boat long sailed.

---

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