Mosh leaves SSH_TTY set in environment, confuses clipetty

[cgull]

Clipetty is an Emacs mode that sends Emacs cuts via OSC 52 commands. It attempts to support double nested tmux (in a chain of tmux -> ssh -> tmux -> emacs) in a hackish way: it writes the OSC 52 to the tty named in SSH_TTY. (It's actually a little smarter than that because it queries tmux for the tmux client SSH_TTY).

This fails in Mosh, because Mosh uses a tty on the SSH connection (which I've never liked), then double-forks, opens its own pty, and lets the parent ssh session exit-- but it never unsets the now-bogus SSH_TTY.

This is mentioned in issue #738. spudlyo/clipetty#20 discusses the behavior/problems from their side.

[eminence]

By similar reasoning, SSH_CONNECTION and SSH_CLIENT should probably be scrubbed from the mosh-server environment too, right?

[bbarenblat]

Mosh leaving SSH_TTY referring to a now-dead TTY is definitely unexpected behavior. The Mosh maintainers are trying to avoid behavioral changes in the next release, but we want to revisit this down the line.

There’s another possible change we could make: Resetting SSH_TTY to refer to the TTY that Mosh creates for its session rather than the TTY associated with the SSH bootstrap. SSH_TTY would then be a bit of a lie. On the other hand, I believe this would fix Clipetty, and it might be less disruptive to other software that looks for SSH_TTY to detect if it’s running inside a remote session.

[eggbean]

I'm finding the same problem with vim-oscyank.

[cgull]

There’s another possible change we could make: Resetting SSH_TTY

I don't think we should do that. To the server, Mosh is a local terminal, mostly. I think we should unset SSH_TTY and set a MOSH_TTY. Then, advanced users can copy it to SSH_TTY to fool unaware programs in their shell profiles/rcs/aliases, programs can recognize they're talking to Mosh and not a bytestream, and unaware users won't be unpleasantly surprised.