in reply to Problem redirecting STDOUT/STDERR

It seems to me that the debugger would lose some utility if it printed all its output to a log. Anyhow...

You might try localizing the handles,

{ open local(*STDOUT), "> $log" or die $!; open local(*STDERR), ">>&STDOUT" or die $!; flock(STDOUT, LOCK_EX | LOCK_NB) or die $!;
Why do you use non-blocking? That will cause you to exit instead of waiting until the file is available. I also don't see why you need truncate, following. You already clobbered the old log when you opened STDOUT.
truncate STDOUT, 0; #clear out STDOUT to start with a fresh log fi +le. chdir $local_dir or die "Cannot change to $local_dir. $!";
I don't know whether $pkunzip makes use of the current directory, but it wouldn't hurt to use Cwd 'chdir'; before this, so that directory changes get into the child's environment.
system $pkunzip, '-doA', "$local_dir/$file"; }
I rewrote the system call to avoid going through the shell. You'll need to call glob yourself if you've been relying on the shell to expand file names to a list.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re: Re: Problem redirecting STDOUT/STDERR
by nimdokk (Vicar) on Jan 16, 2004 at 18:41 UTC
    Thanks, I'll take a look at that. I'm sure that the code can be cleaned up, the process is always on-going :-). For most of our processes, this isn't a big deal, everything works reasonably well but there is one program that dies if it cannot write to STDOUT (either as a file or to the screen).


    "Ex Libris un Peut de Tout"