2 ms·
I tried your example, and observed an error: write /dev/stdout: bad file descriptor What "next file it opens" are you talking about exactly? How does what you'
by echlebek 10y ago
I tried your example, and observed an error: write /dev/stdout: bad file descriptor
What "next file it opens" are you talking about exactly? How does what you're describing work?
- bsdetector 10y agoIn unix when you open a file it gets the lowest available file descriptor number. So if you run a program with no stdout (file descriptor 1) then it gets a "bad file descriptor" error anytime it prints something until a file is opened, gets file descriptor 1, then it starts writing to the file. Example: #include <stdio.h> int main(int argc, char **argv) { printf("first message\n"); fflush(stdout); fopen("output", "w"); printf("second message\n"); fflush(stdout); } Output: # ./a.out first message second message # ./a.out 1>&- # cat output second message By ignoring the error, the program continued on and then wrote console output messages to the file after it was opened. There have been exploits due to this bug, but the real point is that you could never predict this failure without good knowledge of unix and careful consideration. This is why error codes should not be cavalierly ignored, because it's really hard to know what might happen if you do. Last I checked, Go operates the same way as this C example. Java fails on the "first message" if stdout is closed so it doesn't trash the file, not because they even specifically thought of this scenario but just because errors are not ignored by default and are not easy to ignore.