clipetty icon indicating copy to clipboard operation
clipetty copied to clipboard

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

Open whjiang opened this issue 4 years ago • 8 comments

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.

whjiang avatar Apr 09 '20 07:04 whjiang

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 avatar Apr 11 '20 03:04 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.

spudlyo avatar Apr 15 '20 17:04 spudlyo

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.

hartikainen avatar May 27 '20 11:05 hartikainen

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

Mic92 avatar Jul 17 '20 16:07 Mic92

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.

spudlyo avatar Jan 10 '21 01:01 spudlyo

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

pyloolex avatar Jul 13 '23 05:07 pyloolex

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.

z3t0 avatar Feb 18 '24 05:02 z3t0