I have used IPC::Open3 for this and found it
worked well both on Unix and Windows. If
$cmd has your command then:
use IPC::Open3;
open3("<&STDIN", \*CAPTURE, \*CAPTURE, $cmd) or die "Cannot run $cmd:
+$!";
Now you are reading both STDERR and STDOUT of
the file from CAPTURE.
I don't know how to do this and get return codes
as well though, the return of open3 is a process
ID. Also note that you need to be careful with
mixing filehandles. Should you try to get output while it is giving you input, programs take a while to get bored with that sort of silliness... | [reply] [d/l] |
any idea about getting the return code ? :)
| [reply] |
| [reply] |
It can be done by redirecting STDERR to STDOUT:
my $output = `program 2>&1`;
print $output;
| [reply] |
| [reply] [d/l] [select] |
It would probably be easier syntactically to get and use stderr.exe, which pipes both stderr and stdout, to stdout.
| [reply] |
sub phork {
# we will call fork and return a pid. The child will exec with all args
# and suppress the child's output (with /dev/null);
my $pid;
if ($pid = fork) { # fork the process;
#parent
return $pid;
}else
{
#child
die "CANNOT FORK!!\n" unless defined $pid;
open(STDOUT, "/dev/null"); # suppressing output
open(STDERR, "/dev/null"); # suppressing output
{exec(@_);}; # calls exec with current @_
exit(1); # exec may maybe fail... maybe.
}
}
now, if you used the opens to open pipes,
or to open files you want the output in, I'm thinking
it should work in windows too.
I have a question, however, regarding how one would
just disregard STDOUT and STDERR under windows using
this function (there's no /dev/null of course).
Also, when you reap the forked process, you can then
get the return value ($exit_value = $? >> 8;) if you
don't want asynchronocity, then replace exec with
system, and you can get the return value directly from that.
-Daniel | [reply] |
use File::Spec;
sub phork {
#...
open(STDOUT, '> ' . File::Spec->devnull);
open(STDERR, '> ' . File::Spec->devnull);
#...
}
That _should_ do it. | [reply] [d/l] |
In Windows 2000 you can capture both STDOUT and STDERR from an MS-DOS command by combining 1> and 2> like this:
C:\> MyCmd.cmd 1>2>MyLog.log
This keeps the log file text appear the same as it would have appeared on your screen. I only have Windows 2000, so I can't verify it on any other Microsoft OSes. | [reply] [d/l] |
sub phork {
# we will call fork and return a pid. The child will exec with all args
# and suppress the child's output (with /dev/null);
my $pid;
if ($pid = fork) { # fork the process;
#parent
return $pid;
}else
{
#child
die "CANNOT FORK!!\n" unless defined $pid;
open(STDOUT, "/dev/null"); # suppressing output
open(STDERR, "/dev/null"); # suppressing output
{exec(@_);}; # calls exec with current @_
exit(1); # exec may maybe fail... maybe.
}
}
now, if you used the opens to open pipes,
or to open files you want the output in, I'm thinking
it should work in windows too.
I have a question, however, regarding how one would
just disregard STDOUT and STDERR under windows using
this function (there's no /dev/null of course).
-Daniel | [reply] |
use "nul:" instead of "/dev/null" on win32.
| [reply] |