Re: How can I re-open STDOUT?

In the 2-arguments (and 1-argument) form opening '-' opens STDIN and opening '>-' opens STDOUT.

What that basically does is copy the STDOUT filehandle to the first argument of open e.g

shell> perl -le 'open( FH => ">-" ); close STDOUT; print FH "test"'
shell> perl -le 'open(FH => ">&STDOUT");close STDOUT; print FH "test"'
test
[download]

So there you can see that the >- form just copies the STDOUT filehandle, but if it's duplicated then we get the expected behaviour. It would seem that if you close STDOUT you can't open it again (but there's probably some system dependent trickery you can use to get an approximation of it back again).

Update - further research would indicate that you can't re-open STDOUT at all. This is due to the fact that close STDOUT closes the file descriptor pointed to by STDOUT, and since there isn't a way of natively re-creating STDOUT in perl it's gone for good. However, my research hasn't been exhaustive so if this is inaccurate please let me know.
HTH

_________ broquaint

Comment on Re: How can I re-open STDOUT? Download Code

Replies are listed 'Best First'.
Re: Re: How can I re-open STDOUT? by Limbic~Region (Chancellor) on Aug 07, 2003 at 12:40 UTC
broquaint, Thanks for the explanation. I had never tried to close and re-open STDOUT without saving it off first, but assumed it was possible. I looked at IO::Handle but then thought if a module could do it - there should be no reason something less heavy couldn't as well. Looking in the Camel on fileno, it has this to say (paraphrased since I am not sure about copyrights): File descriptors change between opens and closes, but Perl tries to take care of STDERR, STDOUT, STDIN. Ok, not really - it only pays attention to file descriptors that are less than $^F - whose default is 2. So it all works out. Basically you could reopen STDOUT using `open(FILEHANDLE, "<&=$fd")` where $fd is the file descriptor number. It goes on to warn that these can change if you start opening and closing them all willy nilly. Cheers - L~R Update: Per broquaint's /msg to me, this doesn't work. I assumed when the documentation said Perl took special care to look out for certain file descriptors - it meant that it only made it look like you had closed them but it really did the "save so you could restore". Apparently not. After reading perldoc perlvar on $^F - Perl preserves these descriptors during open even in the event of a failure. As we all know - opening up the same filehandle normally closes the original. So if the open fails, you still have STDOUT, and if the open succedes the new handle gets the old descriptor number. Update 2: As broquaint and I argued about this for quite some time in the CB, I am going to provide code to illustrate that the docs are right - even though they are misleading. The Camel is even more misleading IMO. Read more... (1515 Bytes)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: How can I re-open STDOUT?
by Limbic~Region (Chancellor) on Aug 07, 2003 at 12:40 UTC

broquaint

IO::Handle

fileno

File descriptors change between opens and closes, but Perl tries to take care of STDERR, STDOUT, STDIN. Ok, not really - it only pays attention to file descriptors that are less than $^F - whose default is 2. So it all works out. Basically you could reopen STDOUT using open(FILEHANDLE, "<&=$fd") where $fd is the file descriptor number. It goes on to warn that these can change if you start opening and closing them all willy nilly.

Cheers - L~R

Update: Per broquaint's /msg to me, this doesn't work. I assumed when the documentation said Perl took special care to look out for certain file descriptors - it meant that it only made it look like you had closed them but it really did the "save so you could restore". Apparently not. After reading perldoc perlvar on $^F - Perl preserves these descriptors during open even in the event of a failure. As we all know - opening up the same filehandle normally closes the original. So if the open fails, you still have STDOUT, and if the open succedes the new handle gets the old descriptor number.

Update 2: As broquaint and I argued about this for quite some time in the CB, I am going to provide code to illustrate that the docs are right - even though they are misleading. The Camel is even more misleading IMO.