]> git.ipfire.org Git - thirdparty/git.git/commit
test-terminal: drop stdin handling
authorJeff King <peff@peff.net>
Thu, 6 Jun 2024 08:22:37 +0000 (04:22 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 6 Jun 2024 17:07:41 +0000 (10:07 -0700)
commit62c71ace4449df4b22a5d568f3699238ea032495
tree8d3424daacd6e417270a2ec0043373afb8133c1e
parent53ce2e3f0abf356fb0d2638783fe06711c5337d6
test-terminal: drop stdin handling

Since 18d8c26930 (test_terminal: redirect child process' stdin to a pty,
2015-08-04), we set up a pty and copy stdin to the child program. But
this ends up being racy; once we send all of the bytes and close the
descriptor, the child program will no longer see a terminal! isatty()
will return 0, and trying to read may return EIO, even if we didn't yet
get all of the bytes.

This was mentioned even in the commit message of 18d8c26930, but we
hacked around it by just sending an infinite input from /dev/zero (in
the intended case, we only cared about isatty(0), not reading actual
input).

And it came up again recently in:

  https://lore.kernel.org/git/d42a55b1-1ba9-4cfb-9c3d-98ea4d86da33@gmail.com/

where we tried to actually send bytes, but they don't always all come
through. So this interface is somewhat of an accident waiting to happen;
a caller might not even care about stdin being a tty, but will get bit
by the flaky behavior.

One solution would probably be to avoid closing test_terminal's end of
the pty altogether. But then the other side would never see EOF on its
stdin.  That may be OK for some cases, but it's another gotcha that
might cause races or deadlocks, depending on what the child expects to
read.

Let's instead just drop test_terminal's stdin feature completely. Since
the previous commit dropped the two cases from t4153 for which the
feature was originally added, there are no callers left that need it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/test-terminal.perl