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

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

The issue names no files or tests; start at the uv_tty_reset_mode entry point and the tty-handle close path. Reproduce the EBADF behavior on Darwin, then compare the documented atexit use with the duplicated file descriptor lifecycle on Unix systems. Done should include a decided behavior for reset after handle close and coverage for the reported failure.