uv_tty_reset_mode doesn't work as advertised if original handle is closed about libuv HOT 5 OPEN

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)

from libuv.

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.

from libuv.

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

from libuv.

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?

from libuv.

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?

from libuv.