in reply to Re: capturing output of system call inside a thread
in thread capturing output of system call inside a thread

Thanks for the reply. I want to have multiple concurrently running "processes". These "processes" are independent of each other. Each "process" can call system, print to STDOUT and STDERR, but I want outputs (both STDOUT and STDERR) and any output from system() of each of these "processes" to be captured in separate files preferably with STDOUT and STDERR outputs arranged properly. This way I would have meaningful log files for each process. Does that make sense?
  • Comment on Re^2: capturing output of system call inside a thread

Replies are listed 'Best First'.
Re^3: capturing output of system call inside a thread
by BrowserUk (Patriarch) on Sep 03, 2015 at 19:06 UTC
    I want outputs (both STDOUT and STDERR) and any output from system() of each of these "processes" to be captured in separate files preferably with STDOUT and STDERR outputs arranged properly.

    What do you mean by:

    1. "any output from system()"?

      system doesn't produce output.

      Programs run using system produce output; but you've already said you want to capture that.

      So what other output ("produced by system()") are you expecting?

    2. "with STDOUT and STDERR outputs arranged properly"?

      stdout is usually buffered; whereas stderr is usually unbuffered; which means that stuff written to stderr often appears on the console before stuff that was written to stdout chronologically earlier in the execution of the program.

      There is nothing that can be done from outside of the program to influence the that.

      If you have access to the sources of the external programs you are running; you can ensure that both streams are unbuffered; but that has nothing to do with threading, or the perl code that is invoking those programs.

    I think I can suggest something to achieve your goals; but I need you to answer those two questions first.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.
    I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]
      Thanks for the reply again.

      1. Sorry I was imprecise. I've meant that I want to capture output of the program that is being run by system call: STDOUT and STDERR, as well as STDOUT and STDERR produced by perl code in that "process".

      2. You are correct is saying I can't control external program buffering from my perl script. I just want to see in my log file the same thing that I would see on the screen if I were to run that program independently from the command line.

[reply]
        I want to capture output of the program that is being run by system call: STDOUT and STDERR, as well as STDOUT and STDERR produced by perl code in that "process".

        What is the difference between: output of the program that is being run by system call; and STDOUT and STDERR produced by perl code in that "process"?

        Aren't they the same thing?

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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". I knew I was on the right track :)
        In the absence of evidence, opinion is indistinguishable from prejudice.
        I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]

In Section Seekers of Perl Wisdom