Comment 6 for bug 1502197

> but requires replacing the terminal process itself (so when the process exits the terminal app also exits)

True enough. Which might become annoying if you mistype... so what I did, I set up an alias by putting the following into my ~/.bash_aliases :

alias m="exec ssh localhost"

Just typing "m" on its own then gives me a "protected" session.

... or, if you really wanted to fully automate this, you could put the following into your ~/.bashrc:

if [ -z "$SSH_TTY" ] ; then
        exec ssh localhost
fi

... so that each session which is not already an ssh session gets nicely wrapped. But in the end I decided that it was a tad too risky, if ever for some reason sshd stopped setting $SSH_TTY I would effectively have locked me out of my phone...

> It also does not actually allow the process to continue running, it is still paused under the normal lifecycle rules.

The ssh client itself is indeed paused (ps from another session shows it in state T), but any processes running "under" it are left untouched (because they are not actually children of the ssh client, but children of the server which doesn't even notice what happened to its client). And when getting back to the terminal, the ssh client is woken up cleanly, and you can continue to use the session as if nothing had happened. What is all I'd need, really.

> Therefore does not (on it own) solve the issue properly.

Well, at least it makes the issue much less annoying. It doesn't kick me out of vi with a messed up terminal any longer... :-)

Of course, it would still be preferable if the issue was properly fixed in the terminal app, but at least now we have a workaround until a proper fix is ready.