On Tue 2019-05-21 23:17:02 +0300, Tomi Ollila wrote:
> Without this stdin may be anything that parent process provided for it.

I'm fine with this change -- i can confirm that it avoids the hanging
problem on debian stable for me.

please merge either this, or
id:20190521010304.417-1-dkg@fifthhorseman.net . i don't think we need
both.

Tomi's step here is a "big hammer" approach by comparison with my patch
targeting gdb itself, but it's also simple and elegant -- stdin from
outside the test suite has no business interfering with the tests.

> Test processes might have tried to read something from it, which would
> have caused undeterministic behavior.

My only (weak, nagging) concern is that this change may err on the side
of "too much determinism", in the sense that different stdin setups
might more accurately represent "real world" use cases of notmuch than
stdin being mapped to /dev/null.

However, if those different configurations that we happen to get from
random people invoking the test suite in different ways are actually
important, then the test suite should probably try to explicitly
enumerate those cases, and test them regardless of the environment in
which the test suite is run.

> E.g. gdb(1) tries to do tty related ioctls on fd 0 (and fd 1 and fd 2,
> but those are redirected to 'test.output' before test runs).

For the record, these problems were only with moreutils parallel when
used in combination with a specific version of gdb.

if gdb (or some other subprocess (gpg, i'm looking at you)) were to try
to monkey around with /dev/tty, i think even with this "big
hammer" fix, it could do so, because we haven't isolated the tests from
the "controlling terminal" (see tty(4)).

But again, if we run into that, that is probably worth an independent
fix (with "setsid --wait" or something like that, ugh).

        --dkg

PS if we merge this change, does it mean that we can/should remove the
   -tty /dev/null stuff from T380-atomicity.sh?