I realized that I need to be more specific about my requirements.
My perl script calls arbitrary perl subs or scripts which do arbitrary
things. I hope good things. I'm not always sure. I am usually in control
of the subs but sometimes other people are.
I would like to replace the STDERR and
Wiggins d'Anconia wrote:
I can't remember
completely whether you can use it outside of the rest of the POE
environment or not
Nope can't, Unlike Components, Wheels do not stand alone. Each wheel
must be created by a session, and each belongs to their parent session
until it's destroyed.
Have you looked at IO::Tee? It's job is to dupe STDOUT and STDERR to one or
more filehandles.
Nathan Herring wrote:
What I'm thinking is that I'm going to have to open pipes and fork a
child to sit there and watch the pipes and spew information to STDOUT or
STDERR and also back to the
On Wed, Feb 12, 2003 at 08:43:51PM -0800, Nathan Herring wrote:
One of my desired goals is to replace STDERR and STDOUT in such a way
that
1) the command line user still sees them both, and as they are output
(not strangely buffered)
2) I have a log of every snippit of STDERR and STDOUT with
On Wednesday, Feb 12, 2003, at 21:17 US/Pacific, Rob Barris wrote:
I usually just write my scripts to log to a file, and then start up a
separate Terminal window and say
tail -f logfile
But I only do that on stdout and dunno about getting stderr to go to
the same place.
You can just 'open'
On Wednesday, February 12, 2003, at 11:43 PM, Nathan Herring wrote:
Is there something out there that already does this? Or does it on
arbitrary numbers of filehandles/io::handles?
You need to tie your STDERR and STDOUT file handles. Write a custom tie
module and simply tie it to STDERR and
I want to be able to write a perl script that does advanced logging of
both itself and the system() calls it makes.
One of my desired goals is to replace STDERR and STDOUT in such a way
that
1) the command line user still sees them both, and as they are output
(not strangely buffered)
2) I have a
