input: set input stream to blocking on exit

If stdin is non-blocking, many tools (e.g. cat(1), read(1)) which assume
that stdin is blocking, will break in odd ways:

  read: read error: 0: Resource temporarily unavailable
  cat: -: Resource temporarily unavailable
  rm: error closing file

libuv puts stdin in nonblocking mode, and leaves it that way at exit
(this is apparently by design). So, before this commit, this always
works (because the shell clobbers O_NONBLOCK):

  $ nvim --cmd q
  $ read

...but these forms do _not_ work:

  $ nvim --cmd q && read
  $ echo foo | nvim --cmd q && read
  $ nvim && read

After this commit, all of the above forms work.

Background:

https://github.com/fish-shell/fish-shell/commit/437b4397b9cf273922ce7b414bf6626845f15ad0#diff-41f4d294430cd8c36538999d62681ae2
https://github.com/fish-shell/fish-shell/issues/176#issuecomment-15800155

- bash (and other shells: zsh, tcsh, fish), upon returning to the
  foreground, always sets fd 0 back to blocking mode. This practice only
  applies to stdin, _not_ stdout or stderr (in practice these fds may be
  affected anyways).
- bash/zsh/tcsh/fish do _not_ restore the non-blocking status of stdin
  when _resuming a job_.
- We do _not_ save/restore the original flags visible to
  fcntl(F_[SG]ETFL), because (counterintuitively) that isn't expected.

Helped-by: oni-link <knil.ino@gmail.com>

Closes #2086
Closes #2377

---

Note: The following implementation of stream_set_blocking() was
discarded, because it resulted in a failed libuv assertion[1]:

  int stream_set_blocking(int fd, bool blocking)
  {
    uv_pipe_t stream;
    uv_pipe_init(uv_default_loop(), &stream, 0);
    uv_pipe_open(&stream, fd);
    int retval = uv_stream_set_blocking((uv_stream_t *)&stream, blocking);
    uv_close((uv_handle_t *)&stream, NULL);
    return retval;
  }

[1] .deps/build/src/libuv/src/unix/core.c:833: uv__io_stop: Assertion `loop->watchers[w->fd] == w' failed.

0 files changed, 0 insertions, 0 deletions