On Friday, June 14, 2002, at 10:39 , Chas Owens wrote: > This is sort of true. STDOUT is the file that is selected by default; > however, nothing prevents you from selecting a different file (see > perldoc -f select). If STDOUT is closed then I am willing to bet that > some form of log file is selected.
p0: I think chas meant to say 'file descriptor' - or the more appropriate perlishNess - since STDIN|STDOUT|STDERR are not 'writing to files' perse - but to the 'thing the file descriptor' is associated with. p1: I Don't think I have seen anyone actually show how to 'reopen' STDOUT once it has been closed, but I do recall someone talk about running that part to ground - since that really is the 'issue' in the problem here. p2: to help illustrate a part of the problem here - the 'thing' on the other end of the STDOUT - most likely reading from STDIN - will actually 'detect' the 'close' event on STDIN and hence stop processing for incoming stuff.... To Help Illustrate this I propose: http://www.wetware.com/drieux/pbl/Sys/NextStuff/A_pipes_to_b.txt Yes one could play the reopen STDOUT to the thing it was 'duped to' game - per the perldoc open - but that would presume that the puppy had been duped to begin with. ciao drieux --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
