|
Re: STDOUT, STDERR sniffer
by Limbic~Region (Chancellor) on Jul 21, 2004 at 00:00 UTC
|
inguanzo,
There are several ways to do this. You may want to consider one of the easiest and have a look at IO::Tee.
This assumes you want to allow the program to run/output normally but also have a copy of the STDOUT/STDERR output | [reply] |
|
|
IO::Tee is a very nice module, Thks a lot ! But maybe perl is not the solution. The problem is: the script must run several applications (compilation) that write directly to STDOUT, STDERR; those outputs need to be captured and analyzed in order to implement a kind of autoreporting.
What about "script" unix command ? That's exactly what I need, Perl must be able to do something like this.
| [reply] |
|
|
The behavior of script is quite similar to Expect. Maybe that will help, if the problem is that your programs are giving different output because they're not hooked up to ttys.
Or maybe you could describe what IO::Tee isn't doing that you would like it to.
| [reply] |
Re: STDOUT, STDERR sniffer
by Zaxo (Archbishop) on Jul 21, 2004 at 00:01 UTC
|
You reopen each handle to do what you want, for instance in 5.8 you can easily capture to variables,
my ($output, $messages);
{
open local(*STDOUT), '>', \$output or die $!;
open local(*STDERR), '>', \$messages or die $!;
# ...
}
If you prefer, you can open to disk files instead in any version of perl. To capture to variables in earlier versions of perl, you must use IO::Scalar or similar.
| [reply]
[d/l] |
|
|
This code causes 2 uninitialized warnings:
Use of uninitialized value in open.
Use of uninitialized value in open at ./a.pl line 8.
the two errors are from the two open calls.
how can i make the warnings go away ? | [reply]
[d/l] |
Re: STDOUT, STDERR sniffer
by hbo (Monk) on Jul 21, 2004 at 05:12 UTC
|
Or, if you don't mind combining stdout and stderr, you can just do:
$output= `command 2>&1`;
"Even if you are on the right track, you'll get run over if you just sit there." - Will Rogers
| [reply]
[d/l] |
Re: STDOUT, STDERR sniffer
by ercparker (Hermit) on Jul 21, 2004 at 05:28 UTC
|
you can redirect STDOUT and STDERR to seperate files by doing this:
system("app args 1>/tmp/app.stdout 2>/tmp/app.stderr");
| [reply]
[d/l] |
Re: STDOUT, STDERR sniffer
by DrHyde (Prior) on Jul 21, 2004 at 12:26 UTC
|
This question - and variations on it - is frequently asked. IO::Capture is your friend. | [reply] |
Re: STDOUT, STDERR sniffer
by pg (Canon) on Jul 21, 2004 at 07:34 UTC
|
Too much guess here, was the question sort of asked in a way that is over simplified?
If the purpose is solely to capture the result, why Perl script? Personally I dislike the idea to wrap one-liner unix command in a Perl script.
Whether Expect is something you want really depends on whether the output is analyzed right the way, or off line. If the result of the analysis is not useful for the execution itself, Expect is not the right guy. The situation is not clearly described in the original post and follow ups, so cannot say, but I sort of giving you the rule already.
| [reply] |
|
|
The goal is:
USER will compile a big project.
TOOLCHAIN SUPPORT (me) want to track the compilation results (compilation time, success or fail, NFS problem, etc) and mail them.
The USER have to see all the output, so all the reporting process must be transparent for the USER.
It's just a compilation sniffer (STDOUT, STDERR).
Maybe perl is not the solution.
Thinking about your suggestions:
Redirecting the STDERR/STDOUT is not the solution because the user won't have any output.
Tee has to write on Tee object, not directly on STDOUT (If an app write directly to STDOUT, it is not captured to the others filehandlers). I have a question here, is there a way to redirect Tee object to STDOUT ? : *STDOUT = $TeeObj;
| [reply] |
|
|
UPS ! The previous Anonymous Monk was me...
| [reply] |
|
|
|
|