From: Mike Coleman [mailto:[EMAIL PROTECTED]]
> David Nicol <[EMAIL PROTECTED]> writes:
> > > One other possibility, if you're feeling masochistic, is
> > > to simply build the thing yourself, the old-fashioned
> > > way. That is, with pipe(2), fork(2), dup2(2), open(2),
> > > etc. Not needed here, but if you're Doing something
> > > totally unique, sometimes it's the way to go.
> >
> > are you suggesting some kind of wrapper program, like
> > nohup, that would discard stdout, redirect stderr to
> > stdout, and exec its args?
>
> Nope. What I'm suggesting would be basically reimplementing
> that popen3 thing (whatever it's called in Perl) in terms of
> lower level system calls. If you look in the perl source,
> you'll probably see a bunch of those calls. Either that, or
> calls to popen(3) or system(3), in which case you can look
> in the libc source for the lower level calls.
>
> It's pretty tedious stuff, but interesting if you want to
> know how this all really works.
That might be fun for you and David, but the original poster was looking for an easy answer so he wouldn't have to figure out any of the lower level details ;)
It is my understanding that the new PerlIO layer which will be going live in Perl 5.8.0 will be replacing the libc stdio stuff because of its various short comings. Things like the ability handle asynchronous io correctly, other things beyond my ken, etc. One of the things this will finally allow, in the Win32 world, is the possibility of a Win32 implementation of an IO layer to match UNIX filehandles, pipes, and sockets. Instead of the current under-documented state of somethings work and some don't.
This is relevant to the Python world as well, because one of the things Guido expressed interest in, was using PerlIO in conjunction with Perl6/PARROT to make the new Perl IO libraries available to Python.
