[BUG]： clipetty--emit: Opening output file: Permission denied, /dev/pts/3

[whjiang]

Describe the bug
I'm using the newest Doom Emacs with clipetty enabled in a ssh terminal. The client is ITerm2 on Mac and the target ssh machine is a linux docker. And I use dtach for nohup.
When performing delete/copy, I got clipetty--emit: Opening output file: Permission denied, /dev/pts/3.

To Reproduce
Steps to reproduce the behavior:

1. from MAC ITerm2, ssh to linux docker.
2. start emacs with dtach -A /tmp/emacs emacs.
3. make some copy & paste under evil mode.

Expected behavior
no error report.

** System Info (please complete the following information):**

• OS: Linux, macOS
• Emacs Version 26.3
• Terminal program iTerm2
• Any terminal multiplexers in play dtach
• Local or remote (over SSH) ssh

Additional context
Add any other context about the problem here.

[spudlyo]

I think what's happening here is that you have a stale SSH_TTY environment variable. At one point when you were running Emacs under dtach your SSH_TTY was set to /dev/pts/3. At some point in the future, you reconnected using dtach -A on a different tty, but the environment variable in Emacs still pointed to the old tty.

Try starting Emacs like this instead: unset SSH_TTY; dtach -A /tmp/emacs emacs

Since you're not using a multiplexer like Tmux or Screen that intercepts OSC 52 escape sequences, this should just work for you.

[spudlyo]

This seems to happen with some regularity. I should handle this condition in the code, and if I can't write to the SSH_TTY for some reason I should write to stdout as a fallback.

[hartikainen]

I'm regularly seeing this same issue on Ubuntu with tmux + emacs 26 + clipetty. Happy to provide any diagnostics if those would be of any help.

unset SSH_TTY seems to solve the immediate issue for me.

[Mic92]

I am seeing this in combination with mosh. I suppose that SSH_TTY gets stale and mosh does not provide the correct value.

[spudlyo]

This issue is definitely related to relying on SSH_TTY to stop tmux from grabbing the OSC-52 escape sequence and not passing it on. The good news is that there is another way preventing tmux from doing this that involves adding the correct terminfo capabilities via the tmux terminal-overrides option.

I believe that Clipetty can be reworked to do this rather than messing with SSH_TTY which should stop this issue from cropping up, as well as enable Mosh support in #9.

[pyloolex]

It happens to me too. Very often, actually.
I use Iterm2 + tmux + Emacs + clipetty.

[z3t0]

What would a fix for this look like? I can put in the time to implement and submit a patch, just need a little guidance.

[sashkachan]

This happens when using kitty terminal, specifically - kitty ssh <host>. This command enables some extra integration between kitty terminal and the host. I don't use tmux or any other multiplexer.