in reply to Re^3: Synchronizing STDERR and STDOUT
in thread Synchronizing STDERR and STDOUT

Forking isn't portable. Windows only emulates it and it doesn't always do this well.

Update: Also, I don't believe this guarantees that the streams will remain in synch. I've had plenty of problems with Test::Builder output getting corrupted when Test::Harness spits it out and if they must be completely in synch or my code fails.


New address of my CGI Course.

Replies are listed 'Best First'.
Re^5: Synchronizing STDERR and STDOUT
by nothingmuch (Priest) on Sep 21, 2006 at 11:20 UTC
    You missed my point.

    The shell will simply do a dup of 2>&1 like i illustrated. The problem is not in the fork, etc, but in that the sugar layer to do this dup, namely 2>&1 involves reparsing the command line, etc, and is thus undesirable and unportable.

    Instead of staying one level above backticks and shell redirects, you can simply do what they do.

    As for fork vs no fork - look at how IPC::Run does it. It's portable to windows and supports redirects.

    WRT synching - i am not sure (this may be impl dependant) but if there are two separate buffers for the predupped handled then they won't be in synch unless you auto flush in the child. If two dupped file descriptors will share a buffer then they will be completely synchronized, and in either case this is not going to be any different than what 2>&1 will give you.

    zz zZ Z Z #!perl