tty: internal mode state does not account for changes outside of libuv

[wavexx]

When changing the tty mode (via uv_tty_set_mode), we keep an internal "mode" state to avoid doing ioctls again. I see this is used to restore the original terminal mode, but it introduces some issues.

When using a pty to control a slave process, the slave might change the mode on our back. I have this problem on a couple of occasions, where I need to force a call to cfmakeraw() but I need to toggle the internal state (by changing the tty mode to NORMAL and then IO again) to actually do it.

I'd be tempted to add a "force" parameter to always set the requested mode, but maybe there's a better solution?

[bnoordhuis]

Are you referring to the if (mode == tty_handle->mode) return 0 check? I'd be okay with removing that provided it's replaced with a comment explaining why libuv doesn't do an early exit - and assuming it doesn't cause regressions, of course.

[wavexx]

On Fri, Apr 07 2017, Ben Noordhuis wrote: Are you referring to the if (mode == tty_handle->mode) return 0 check?

Precisely. I'd be more inclined to rename the mode field to "inited/initialized" as well, so that it's clear that we use it to store the orig_termios status for uv_tty_reset_mode. You cannot easily "get" the tty mode back.

I'd be okay with removing that provided it's replaced with a comment explaining why libuv doesn't do an early exit - and assuming it doesn't cause regressions, of course.

Aside the tests in libuv, I also run Julia tests and my expect-like wrapper (which I why I incur in this issue).

[wavexx]

See PR #1293

After reviewing the code, I really don't like how uv_tty_reset_mode() works. I didn't change its behavior, but it works on the assumption that you only change one TTY. If you're working with multiple PTYs, uv_tty_reset_mode resets the tty which was first modified, which is senseless. Changing the behavior without changing the ABI though is tough.

I hope it's more clear in the docs now.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vtjnash]

In progress/discussion in #1293?

[wavexx]

Didn't touch tty code in a while, I resorted to an external process helper.
I'm working on completely different stuff currently, but I still consider this an issue if one wants to do proper tty manipulation.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[wavexx]

On Thu, Oct 01 2020, Jameson Nash wrote: Reopened #1292.

Bad stale[bot]!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.