BUG: "Can't set selection" error in emacs when emacs started from remote shell

[vincent-opdarw@…]

When I run emacs (from the emacs-devel port) in an environment where the SECURITYSESSIONID variable isn't set (this can happen when emacs is started from the screen utility), copy-paste between emacs and other applications fails. For instance, when I click with the middle button to paste in emacs, I get the error "Kill ring is empty".

[vincent-opdarw@…]

In fact the behavior is quite random. Sometimes it works. Sometimes it works only when the selection has been pasted first to Sticky. Strange...

[vincent-opdarw@…]

I'm changing the summary because this has nothing to do with SECURITYSESSIONID: even when set manually, I can get an error. To reproduce the problem:

1. Connect to the Mac OS X machine with ssh.
2. Start the "screen" utility.
3. Detach the screen session (and quit ssh).
4. Reattach the screen session from a Mac OS X terminal (in my case, iTerm).
5. Type /Applications/DarwinPorts/Emacs.app/Contents/MacOS/Emacs.
6. Type something in Emacs and select something.

In the messages, I get the error:

x-set-selection: Can't set selection

Copy-paste (with the mouse or the keyboard) works inside Emacs, but only inside Emacs, not with the other Mac OS X applications, i.e. the Mac OS X clipboard is not transmitted to Emacs, ditto for the other way round. Cutting a selection by double-clicking with the right mouse button doesn't work either.

My current active port: emacs-devel @22.0.50.1-20060622_2+atsui+carbon+darwin_8

[jmroot (Joshua Root)]

Closing: emacs-devel was removed in r33465.

[vinc17@…]

I'm reopening the bug since it applies to the emacs port too (not surprising, since this is the same software). I reproduced it with: emacs @22.2_1+atsui+carbon

[(none)]

Milestone Port Bugs deleted

[vinc17@…]

archive containing the dump files obtained with ktrace/kdump and the corresponding environment

[vinc17@…]

The bug still occurs with Emacs 22.3.1. The attachment kdump-mp6495.tar.lzma contains the dump files obtained with

  ktrace /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs \
    -q -no-site-file -eval '(setq inhibit-splash-screen t)'

and kdump, and the corresponding environments. In the Emacs window, I typed "asd" and selected it with a double-click. Then I quit Emacs with C-x C-c.

*-fail when Emacs has been started from screen (see above).

*-ok when Emacs has been started from a normal iTerm tab.

In kdump-ok, the PID has been changed to the PID from kdump-fail in order to be able to do a "diff".

It seems that the main differences in the kdump files are the failures of shm_open in kdump-fail: "shm_open -1 errno 2 No such file or directory".

[drkp (Dan Ports)]

Cc Me!

[drkp (Dan Ports)]

I recently (and independently) noticed this myself. It looks like the real problem here is that emacs is unable to access the pasteboard when started from within screen. It seems that [NSPasteboard generalPasteboard] returns nil, although I've been unable to find out why.

I'm no longer looking into this, but here is a link to the bug I filed against emacs:

​http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4070

[drkp (Dan Ports)]

And... 4 years later, I believe I have the solution to this bug.

Under 10.5 and earlier, anything started from screen was unable to communicate with the pasteboard server because the pasteboard server is in the per-session bootstrap context and screen has to disassociate itself from the per-session context in order to persist across sessions.

Happily, under 10.6 this is now moot as the distinction between per-user and per-session contexts is evidently gone. I'm not able to reproduce anymore under 10.6.

For more details, see the comment I just added to ​http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4070 (and also compare #18235)

[vinc17@…]

Unfortunately, I'm under 10.4 and I can't upgrade due to hardware compatibility.

Also, the last comment is a bit incorrect, at least under 10.4: if screen is started in iTerm, for instance, then copy-paste works fine. The only problem is when screen is started from a SSH session.

I'd like to know how the per-session context works, in order to see whether there's a work around.

[drkp (Dan Ports)]

Replying to vinc17@…:

Also, the last comment is a bit incorrect, at least under 10.4: if screen is started in iTerm, for instance, then copy-paste works fine. The only problem is when screen is started from a SSH session.

I stand corrected -- I think screen only behaves that way under 10.5. Under 10.4, I think it wasn't doing anything special with regards to launchd and contexts, although I'm not entirely sure since I can't tell what version of screen (and what Apple patches) shipped with 10.4.

I'd like to know how the per-session context works, in order to see whether there's a work around.

Looks like things were a bit different in this respect with 10.4 too. I think basically each login (GUI or ssh) was in its own session context, without a per-user namespace shared among all of that user's contexts. In other words, even if screen isn't doing anything special, anything started from a ssh session won't be able to access the pasteboard server. So I wouldn't be too hopeful about getting it to copy-paste correctly. You *might* be able to work around it using launchctl bsexec if that's available in 10.4.

For reference, you might want to take a look at this Apple TN: ​http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html It's mostly about 10.5, but has some info about earlier versions at the end. Unfortunately, nothing about 10.6.

[vinc17@…]

Replying to dports@…:

I stand corrected -- I think screen only behaves that way under 10.5. Under 10.4, I think it wasn't doing anything special with regards to launchd and contexts, although I'm not entirely sure since I can't tell what version of screen (and what Apple patches) shipped with 10.4.

I'm using screen from MacPorts (ditto for sshd, from the openssh port).

[...] You *might* be able to work around it using launchctl bsexec if that's available in 10.4.

It isn't available.

For reference, you might want to take a look at this Apple TN: ​http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html

Thanks. That's a bit complex. I wonder whether it is possible to change the namespace, or to run an application in a different, existing context (possibly with the help of an agent running in this context).

[drkp (Dan Ports)]

This isn't a problem under Snow Leopard and not fixable under Leopard/Tiger because of their launchd session contexts. Would be interested to hear if there's a workaround but it seems unlikely without significant effort.