Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^4: exec always invokes the shell? win32

by Anonymous Monk
on Feb 10, 2011 at 18:04 UTC ( [id://887509]=note: print w/replies, xml ) Need Help??


in reply to Re^3: exec always invokes the shell? win32
in thread exec always invokes the shell? win32

Then how come system doesn't have the same problem?

I appreciate you trying to help, but sorry, you simply have no idea what you're talking about

  • Comment on Re^4: exec always invokes the shell? win32

Replies are listed 'Best First'.
Re^5: exec always invokes the shell? win32
by ELISHEVA (Prior) on Feb 10, 2011 at 21:00 UTC

    The question "why is exec splitting "1 2" into "1" and "2", but system does not is a good question. The conclusion that exec always calls the shell is not.

    Quite simply, your theory is counter to the Perl documentation and the intent of both system and exec. Neither exec nor system call the shell except possibly in the case that someone tries to exec a shell built-in. If you want the shell invoked, you use backticks. exec and system use native systems calls whenever possible.

    In the case of Ms-Win, exec first tries a direct call on the program via CreateProcess. The shell is only invoked if this calls fails or certain internal Perl limits on the number of wait objects are reached.. Both exec and system use the same code. The only difference between the two is a single mode code (P_WAIT vs. P_NOWAIT). This does not affect parameter handling. You can confirm this yourself by looking at the source code yourself.

    As regards parameter mangling. CreateProcess takes a string, not an array, so Perl collapses your arguments into a single string. (Confirmed by source diving). What actually happens after that depends on the how the receiving program chooses to parse the command line string.

    As for the differences in their behavior, based on reading the Perl source code, I see two possibilities:

    • system did not fail and exec did. Hence one went through cmd.exe and the other did not. There are two possible causes for failure. Inside Perl, there is a maximum limit on the number of wait objects. This affects exec but not system. However, unless your perl is compiled with very low limit (0?) that isn't likely going to be an issue in your script. Outside Perl in the Ms-Windows environment, you'd have to look for some sort of resource allocation problem that affects exec'd processes but not waited upon processes.

    • You are using a perl compiled from a different codebase than the one I'm looking at. The codebase linked to above is the main Perl codebase. However, there is more than one MsWin codebase for Perl (Active State, for instance, uses some of its own proprietary sources). Or perhaps you are working with an older release of an open source version of Perl.

    Finally, you should know that not all platforms get the results you did. The behavior I get running your script on a Linux box does not show any difference between system and exec. "1 2" does not split into two parameters (hardly surprising since linux takes an parameter array not a command line string). Also I get the reverse behavior you do: no args has no output, 1 arg has output:

    $ perl Anony.pl perl -l -e "print for @ARGV" -- 1 2 system at Anony.pl line 19. exec at Anony.pl line 22. $ perl Anony.pm 1 perl -l -e print for @ARGV 1 2 system at Anony.pl line 19. 1 2 exec at Anony.pl line 22. 1 2

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://887509]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (3)
As of 2024-04-19 19:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found