In unix, file descriptors (fd) identify opened files in system calls. Certain file descriptors have an assumed meaning:
0: Standard Input
1: Standard Output
2: Standard Error
Your program first closes STDIN, releasing fd 0.
Then it opens STDOUT. The system will use the first available fd, namely 0, to reference this open file.
Perl recognizes that fd 0 is write-only and issues the warning.
Messing with STDIN and STDOUT is usually done before calling exec. This warning is useful because the executed program expects fd 0 to be readable, but it's not.
You probably shoulnd't be messing with STDIN and STDOUT. Use other names for your file handles.
| [reply] [d/l] |
I tried the code sample you provided, and the results are the same (as you know). 'Normal' behavior for open/fopen in C/unix is to use the lowest available file descriptor. However, when I run it, either on 5.8.4 or 5.6.0, the behavior is the same: STDOUT gets fd 1, even though fd 0 is available. If I open another file before re-opening STDOUT:
open STDIN, "<$file" or die "can't open STDIN from $file - $!\n";
my @data = <STDIN>;
my $chk1 = sprintf "STDIN file num is %d", fileno(STDIN);
print STDERR $chk1."\n";
close STDIN or die "error closing STDIN - $!\n";
open TMP, "<$file";
$chk1 = sprintf "TMP file num is %d", fileno(TMP);
print STDERR $chk1."\n";
I get what you would expect: the same result, but without the warning. I think the warning is telling you that perl won't violate the conventions that ikegami mentioned. You could get around this fairly easily if you simply move the close of STDIN to follow the open of STDOUT. Keep in mind, though, that by doing this, fd 0 becomes available, and you will get the same warning if the next open is not read-only.
As ikegami said, don't mess with the STD* filehandles unless you doing an exec. | [reply] [d/l] |