search

spudlyo / clipetty

Manipulate the system (clip)board with (e)macs from a (tty)
GNU General Public License v3.0
167 stars 13 forks source link

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

Open whjiang opened 4 years ago

whjiang commented 4 years ago

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):

Additional context Add any other context about the problem here.

spudlyo commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

spudlyo commented 3 years ago

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 commented 1 year ago

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

z3t0 commented 6 months ago

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 commented 3 months ago

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.