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.