[mercury-users] rotd-2007-02-10 won't compile on Ubuntu

Julien Fischer juliensf at csse.unimelb.edu.au
Thu Feb 15 01:34:18 AEDT 2007

On Wed, 14 Feb 2007, Michael Day wrote:

>> We've noticed this problem with Debian testing but only when you build
>> Mercury under nohup.  Are you using nohup?
> This problem affects every Mercury program running when stdin or stdout is 
> closed, thanks to mercury_init_io:
>    MR_file(mercury_stdin_binary) = fdopen(dup(fileno(stdin)), ""rb"");
>    if (MR_file(mercury_stdin_binary) == NULL) {
>        MR_fatal_error(""error opening standard input stream in ""
>            ""binary mode:\\n\\tfdopen() failed: %s"",
>            strerror(errno));
>    }
>    MR_file(mercury_stdout_binary) = fdopen(dup(fileno(stdout)), ""wb"");
>    if (MR_file(mercury_stdout_binary) == NULL) {
>        MR_fatal_error(""error opening standard output stream in ""
>            ""binary mode:\\n\\tfdopen() failed: %s"",
>            strerror(errno));
>    }

That's a separate (but related) problem.

Ondrej's problem is caused by a recent change in behaviour in GNU nohup.
That's why it only affects recent versions of Debian (or distributions based
on it, like Ubuntu).

Previously, nohup's treatment of stdin wasn't documented.  The new (and
documented) behaviour is that if stdin is a terminal then it is redirected
from /dev/null.  The problem is caused by the fact that nohup opens /dev/null
in write mode (according to the nohup code this is so that accidental will
reads cause an error - this isn't in the documentation).  So now stdin is
opened for writing we call fdopen with the mode set for reading and you're not
allowed to do that and so on and so forth until we end up where we began.

The (documented) way to avoid this behaviour is to explicitly redirect stdin
from /dev/null on the command line when invoking nohup, e.g.

 	nohup command < /dev/null

> The fatal error is even more annoying for programs that don't actually *use* 
> stdin or stdout in binary mode; it seems like it would be better if Mercury 
> handled this more gracefully.

I'm open to suggestions on how to handle this one more gracefully.

mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au

More information about the users mailing list