|
|
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.
|
