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