in reply to Re: system and wildcard expansion?
in thread system and wildcard expansion?

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.


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

Replies are listed 'Best First'.
Re^3: system and wildcard expansion?
by rovf (Priest) on Nov 12, 2010 at 09:15 UTC
    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

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