Closed theeternalsw0rd closed 1 year ago
This seems to be useful, because I also get some troubles while copying text from the remote end.
But isn't the feature beyond the range that should be covered by mosh? I'm not against the idea, just curious as I'm not familiar with the mosh development. If it is determined to be OK, I may consider working on this. Any ideas from others?
Having the server be able to send arbitrary content to the client's clipboard might not be so good if you don't trust the server, so this would have to be something that could be turned off (and probably should default to off).
I noticed the hterm terminal emulation that runs in chrome supports OSC52 to write to the clipboard but doesn't allow read for obvious security reasons. It only supports a limited number of characters but I have found it good enough.
I can use this with the chrome Secure Shell packaged app and a remote shell command or a vim plugin to send to my clipboard. If I go through a mosh session, either using mosh compiled with nacl into a packaged app or out of an ssh session I lose this ability. I expect it is something in mosh's terminal emulation. Is there any chance this could be passed through? Then any questions about security can be left to the users terminal emulator to decide.
Interestingly tmux also blocks this sequence as does screen. The hterm example bypasses screen by chunking the sequence and passing it in DCS sequences but that doesn't work with mosh either.
This is said to work if your mosh-client is OSX and your connection doesn't get interrupted, but yea, having mosh support ssh's RemoteForward would be better: https://github.com/wincent/clipper#configuring-mosh
Hope mosh has this feature as well! Remote clipboard over mosh would be very useful.
Marking this as a duplicate of #637 which has open PRs
It would be awesome if there was some way to send text from the server to the client.
The way it would work:
mosh-server would need to be able to take input from stdin and send it to mosh-client in much the same way that the text in the terminal is sent over. mosh-client would need to be able to receive the buffer from mosh-server and be able to store it in a user-specific manner. The user should be able to have mosh-client grab the most recent buffer and place it in stdout.
Use case:
Open a file in vim on the remote end. Make a selection in visual mode. Press a hotkey that runs a command on mosh-server saving the text in the session buffer. Or select some text in a tmux pane that's configured to run the command on the selection. On the local side, press a hotkey that runs a command on mosh-client grabbing the buffer and piping it to pbcopy/xclip/clip or whatever the local side wants to use.
Why not just copy with the mouse?
Terminals have problems with split buffers, so any of these scenarios make copying text to the local end problematic: vim with line numbers; vim with split windows; anything inside a tmux pane. I'm sure there are other scenarios as well.
Why only copy?
mosh already handles local pasting fine, so there's really only the need for remote copy.
Why should mosh do this and not something else?
There's already a connection using mosh that sends text back and forth, so why make some other protocol that uses yet another port and connection? It might be nicer if terminals would be fixed to be more content aware, but that would I think be a much larger undertaking than this.