in reply to Test whether STDOUT is connected to a file

system(1,['perl.exe','myProg.pl','>out.txt','2>&1'])
This doesn't seem to be useful. It calls the program '1', passing it one argument, the value of the stringification of the arrayref.

But perhaps this isn't the system we all know about. Perhaps it's a wrapper around something. Something that constructs the actual call to system. Now, the syntax suggest system is called with a list of arguments. Which means, no shell will be invoked. Which means, there's nothing out there that's actually going to interpret the > symbols. (And my bet is, myProg.pl ignores its arguments).

Replies are listed 'Best First'.
Re^2: Test whether STDOUT is connected to a file
by rovf (Priest) on Aug 18, 2010 at 13:51 UTC
    If the first argument to system is 1, it creates a process in the background. Unfortnately, this is not documented in system. See perlport for the details.

    -- 
    Ronald Fischer <ynnor@mm.st>
      Indeed, so it does. I checked perlport before writing my post, but somehow, I manage to miss this. It does, however, say system(1, @args), not system(1, [@args]). And I assume it's equivalent to system(@args), which, as I said, results in calling perl.exe with three arguments: myProg.pl, >out.txt, and 2>&1. Try this instead: system(1, "perl.exe myProg.pl >out.txt 2>&1") or system("perl.exe myProg.pl >out.txt 2>&1 &")
        Try this instead: system(1, "perl.exe myProg.pl >out.txt 2>&1") or system("perl.exe myProg.pl >out.txt 2>&1 &")
        Though this would work, it would create an intermediary CMD.EXE process, and this is something I want to avoid. This is related to the issues discussed in waitpid returns -1 for still running child - I didn't mention this to not complicate things further.

        I now use the workaround of having the called process check whether it is still connected to a terminal, and if it is, redirect STDOUT. The solution is not really satisfying, because it opens up its own problems, but for the time being it works. I hope to find something better eventually.

        -- 
        Ronald Fischer <ynnor@mm.st>