A program writing to a read-only stdout should not succeed
In the shell, redirection of file descriptors can be read-only (<), write-only (>), or read-write (<>).
A program trying to write to stdout, while stdout is redirected read-only, currently exits with exit code 0.
$ cat hello.hs
main = print "hello world"
$ ghc hello.hs
...
$ ./hello 1< /dev/null; echo Exit status: $?
Exit status: 0
This should however show some error message, and return some non-zero error message, because the write never succeeds.
Note that this example is different from ./hello 1> /dev/null
, which rightfully does succeed.
As suggested by this blog post:
"If you’re not sure why this is important, imagine the command is
dump-database > backup
and the filesystem is full."
Supposedly OCaml gets this right.
For reference, from my bash man page:
- Redirecting Input*
Redirection of input causes the file whose name results from the expansion of word to be opened for reading on file descriptor n, or the standard input (file descriptor 0) if n is not specified.
The general format for redirecting input is:
[n]<word
Trac metadata
Trac field | Value |
---|---|
Version | 7.10.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |