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

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

Replies are listed 'Best First'.
Re^7: system and wildcard expansion?
by rovf (Priest) on Nov 12, 2010 at 11:49 UTC
    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.
    I think what the perldocs say is that bypassing the shell is an optimization. Being a language not bound to a particular operating system, I think it is not practical to document in advance how this will be handled in general. As in your case with a call invoking file association, it is very natural that system uses the shell.
    Personally, I wish Perl would simply pass single scalars directly to the shell and let it work out what happens.
    You can always enforce it, by writing system('cmd /c Your Command Goes Here').
    As is the standard Windows practice of looking in the current directory for executables before chasing the path.
    AFIK, this behaviour is kept even if the shell is not involved.

    -- 
    Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]
[select]
      AFIK, this behaviour is kept even if the shell is not involved.

      Apparently not. From win32.c source (circa line 4225): 

          /* initial NULL argument to CreateProcess() does a PATH
     * search, but it always first looks in the directory
     * where the current process was started, which behavior
     * is undesirable for backward compatibility.  So we
     * jump through our own hoops by picking out the path
     * we really want it to use. */

      [download]
      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.
[reply]
[d/l]
        Clever! I didn't notice it, because (out of my dangerous habit when using Unix), I always kept '.' in the PATH...

        Thanks for pointing this out.

        -- 
        Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]

In Section Seekers of Perl Wisdom