in reply to Re^3: exec vs. backtick-and-assign performance
in thread exec vs. backtick-and-assign performance

Running the program manually takes effectively zero seconds, as indicated by my mentions of the fact that running it with exec() is essentially instantaneous.

Your reference to exec() being the "only way to start a new program" makes me think you're talking about the system call exec(), as opposed to the Perl function (which calls the unix system call). Is that what was meant in the previous post, then? I thought it was referring to the Perl function.

print substr("Just another Perl hacker", 0, -2);
- apotheon
CopyWrite Chad Perrin

  • Comment on Re^4: exec vs. backtick-and-assign performance

Replies are listed 'Best First'.
Re^5: exec vs. backtick-and-assign performance
by Joost (Canon) on Nov 13, 2006 at 00:08 UTC
    Well perl's exec() function as far as I know does nothing more than call the sytem's exec(). update: but yes, I meant the underlying mechanics, not perl's buildin functions.

    Running the program manually takes effectively zero seconds, as indicated by my mentions of the fact that running it with exec() is essentially instantaneous.

    I thought you meant it started immediately, I didn't see anything about it also finishing quickly.

    It may be that the command is checking slowed down / confused by the capturing of it's STDOUT. it might be looking for a tty or something similar. In that case, the easiest solution should be to use system() (or exec(), ofcourse)

      "It may be that the command is checking slowed down / confused by the capturing of it's STDOUT. it might be looking for a tty or something similar."
      I guess that's the best idea I've heard so far for why it might behave like that. Anyone here know if restarting networking in Debian involves some kind of tty checking?

      print substr("Just another Perl hacker", 0, -2);
      - apotheon
      CopyWrite Chad Perrin