On Thu, Feb 7, 2013 at 9:54 PM, David Golden <xdg@xdg.me> wrote: > On Thu, Feb 7, 2013 at 3:32 PM, Eirik Berg Hanssen > <Eirik-Berg.Hanssen@allverden.no> wrote: > > That seems like a perfectly good answer – to a different question. ;-) > > It was the answer to why we should stay of fd 0 and avoid the problem. > Mhm. To bad it's not easily controllable. In answer to your question, probably because having a write-only > handle on a descriptor that programs expect to read from makes them > crash: > But that's not related to the reopening. A closed STDIN will also have the program crashing: eirik@bluebird[22:08:26]~$ perl -wE 'close STDIN; system "/bin/cat"; say $?;' /bin/cat: -: Bad file descriptor /bin/cat: closing standard input: Bad file descriptor 256 eirik@bluebird[22:08:34]~$ perl -wE 'close STDIN; open my $fh, ">", "test"; system "/bin/cat"; say $?;' Filehandle STDIN reopened as $fh only for output at -e line 1. /bin/cat: -: Bad file descriptor 256 eirik@bluebird[22:08:36]~$ Okay, those are slightly different chrashes (for cat; I've tried a few others, but got no difference), but I don't see how that difference has only one of them meriting a warning. (Perhaps there are other instances where this difference makes a significant difference?) If both should warn, the trigger should be executing a process with no fd0 opened for reading. But currently, only one of them warns ... and I still cannot say I see a reason for it. EirikThread Previous | Thread Next