Open cgull opened 3 years ago
By similar reasoning, SSH_CONNECTION
and SSH_CLIENT
should probably be scrubbed from the mosh-server environment too, right?
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.
I'm finding the same problem with vim-oscyank.
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.
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 clientSSH_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. https://github.com/spudlyo/clipetty/issues/20 discusses the behavior/problems from their side.