Re: STDOUT, STDERR sniffer

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.

Comment on Re: STDOUT, STDERR sniffer

Replies are listed 'Best First'.
Re^2: STDOUT, STDERR sniffer by Anonymous Monk on Jul 21, 2004 at 17:28 UTC
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]
Re^3: STDOUT, STDERR sniffer by inguanzo (Acolyte) on Jul 21, 2004 at 18:13 UTC
UPS ! The previous Anonymous Monk was me...	[reply]
Re^4: STDOUT, STDERR sniffer by mhi (Friar) on Jul 22, 2004 at 08:14 UTC
You're joshin', inguanzo! :-)	[reply]
Re^4: STDOUT, STDERR sniffer by inguanzo (Acolyte) on Jul 22, 2004 at 01:40 UTC
Hi all cool monks around, I found the solution to my implementation: Tee is a nice perl module, I suppose the name comes from the tee unix command. I mixed 2 scripts (shell & perl), shell for capture and perl for analize & reporting: Shell script: `build_project_command 2>&1 \| tee ~/rep/DATE_TIME_PRODUCT analize_report_mail.pl ~/rep/DATE_TIME_PRODUCT` [download] Modify the .profile (PATH priority) and give the same name the real compiler has. Now the user will continue compiling as before, the output still untouched and toolchain support guy happy ! So, now we are able to know & evaluate the performance of the compilation environment at real time. Thanks a lot for all your replies and help Inguanzo >emacs rules<	[reply] [d/l]