uv_tty_reset_mode doesn't work as advertised if original handle is closed

[saghul]

In the docs we describe it like so:

To be called when the program exits. Resets TTY settings to default values for the next process to take over.

That somewhat (together with the fact Node uses it that way too) suggests one can call it from an atexit handler to restore the original mode.

Well, that only works if the tty handle isn't closed. Since we reopen the fd when it refers to a tty (the typical case of a REPL), the internal orig_termios_fd reference will point to the duplicated fd, not the real one. When the handle is closed that fd will be invalid and uv_tty_reset_mode will fail with EBADF.

I guess there are 2 bugs here:

1. We should reset orig_termios_fd if the tty handle is closed, since the fd will become invalid.

2. Can we save the original fd so we can restore the mode even after the tty handle is closed? Not sure about this one since we don't store the fd but just the duplicated one. An option (strawman proposal!) could be some UV_TTY_MODE_RESET_ON_CLOSE flag that can be or-ed with the mode, so we auto-reset it upon handle close.

Thoughts?

• Version: all since we started dup-ing the tty fd
• Platform: Only tested on Darwin, but I suspect all Unices

[vtjnash]

Probably also a duplicate of #2062 where the dup2 behavior interferes with the correct behavior of native libraries and uv_spawn also and that native libraries can corrupt libuv state (fwiw, Julia always passes in dup of stdio handles instead of 0,1,2 so that those issues do not occur)

[saghul]

Similar yeah. I guess my reason to think this one is slightly different is that we have dedicated functionality to interact with the outside world, but it has some iinteresting caveats.

[bnoordhuis]

We should reset orig_termios_fd if the tty handle is closed, since the fd will become invalid.

#4399 - imperfect but ceteris paribus an improvement

[vtjnash]

the internal orig_termios_fd reference will point to the duplicated fd, not the real one

To be clear, my recollection is that libuv then calls dup2 to destroy the original fd so that it can point to the "real" one not the duplicated one (which is the bug in #2062)

Secondly, should we add a uv_tty_capture_mode(uv_os_handle_t fd) function, so that this applications can avoid having this code be conditional on whatever pty object first happens to used with it, and so the user could capture the state of fd 0 explicitly instead?

[saghul]

Not sure, I find the current behavior good, minus a specific case...

The PR Ben made solves it already, so I guess we can get more creative if / when we need to?