Open normanr opened 4 years ago
Hmm. In what situation would this be useful? mosh-client keeps its tty in raw mode, so it’ll never get SIGTSTP while it’s the foreground tty process, and SIGSTOP is the appropriate signal to use outside mosh-client. My first take is that mosh-client should ignore SIGTSTP altogether. But what’s your use case?
The use-case for this is that I have another process that needs to briefly interact with the user on same terminal, so it needs to be able to pause mosh-client momentarily. While it works to send SIGSTOP and reset the terminal manually, it would be nicer if it were possible to get mosh-client to reset the terminal itself.
mosh-client already handles SIGCONT, and I don't mind which signal it uses for this. SIGUSR1 would work too, but SIGTSTP seemed to be a better match (particularly because the default behavior of SIGTSTP is to stop the process).
mosh-client should pause the terminal nicely if it receives SIGTSTP. The current code in process_user_input would just call a new pause function, and the current terminal restoration logic & SIGSTOP would move to the new handler function (which would also be executed when SIGTSTP is received). I'm not sure that resume needs to be called after SIGSTOP as SIGCONT should cause it to be called already (although calling resume twice should be fine).