Does not work with osx 10.5.8

[bmihelac]

Is it possible to use this wrapper with osx 10.5.8?

[ChrisJohnsen]

I would have expected it to work correctly under 10.5, but I have never had a version of Leopard to test against.

• Are you using reattach-to-user-namespace under tmux or some other environment?
• How are you using it?
  • wrapping your shells via tmux default-command? (as described in the README)
  • directly with a program that needs access to the bootstrap namespace?
    e.g. path/to/reattach-to-user-namespace pbpaste
• How, exactly, does it fail?
  • Are there any error messages from reattach-to-user-namespace?
    Note that if you are using it via default-command any messages from reattach-to-user-namespace would show up when tmux is starting a new pane/window/session, not when you try to use a program that needs the user bootstrap namespace (i.e. not when you use pbpaste).

If you want to experiment, the test program included with the code offers ways to emulate various situations (e.g. the post-daemon environment that tmux uses) and various techniques to attempt to regain access to the user bootstrap namespace. The section titled “ The Diagnostic Program” in the README offers some examples (though, you will probably want to use move-to-user=10.5 instead of move-to-user=10.6.

---

The core technique that I use in reattach-to-user-namespace is the same thing that the Apple-patched, 10.5-bundled version of screen does: call _vprocmgr_move_subset_to_user(uid, "Background") (see screen-12/screen/screen.c). Under 10.5 I make nearly the exact same call as Apple published. Under 10.6 the function acquired an extra parameter, so the only difference under 10.6 and 10.7 is to add an extra parameter to the call: _vprocmgr_move_subset_to_user(uid, "Background", 0). The value of the extra parameter actually seems to be irrelevant since it is never used when the second parameter is "Background" (see the 10.6 implementation of _vprocmgr_move_subset_to_user in launchd-328/launchd/src/libvproc.c; the only use of flags is conditional on ! is_bkgd, which is false the second parameter is "Background").

[bmihelac]

Hi Chris,

1. yes I try to use it under the tmux
2. I am wrapping it via default-command
3. I don't see any error messages. When I open new window I do see reattach-to-user-namespace echoed in status bar and the window name is renamed to 1:zsh (I normally use bash)

[bmihelac]

This is a result of the test command:

$ ./test daemon=sys system=pbpaste
$ system(pbpaste) process exited 1

$ ./test daemon=sys move-to-user=10.5 system=pbpaste
$ system(pbpaste) process exited 1

[ChrisJohnsen]

The temporary appearance of reattach-to-user-namespace in the status line is normal with the default tmux automatic-rename setting (it periodically renames the window according to the tty’s currently active process). You can, of course, change zsh to bash in your default-command value if you would rather use Bash by default in your tmux sessions.

The wrapper and test programs have error/warning messages for pretty much every possible error situation; so, apparently, none of the functions they call (including _vprocmgr_move_subset_to_user) are returning an error result.

Here are some “sanity checks” and possible avenues for investigation:

1. First, verify that pbaste works in a “plain” Terminal window (i.e. not inside a tmux session, so that tmux is not involved).
   If this fails, then you may be dealing with some other problem:
   • Does pbcopy work? Maybe the problem is just with pbpaste.
     1. In TextEdit, type “foobar”, select it, and Copy it.
     2. Type echo testing 1 2 3 | pbcopy into a Terminal window that is not running tmux.
     3. Paste into TextEdit.
        Did you get “foobar” or “testing 1 2 3”?
   • Are you sure you are running pbpaste (and pbcopy) from /usr/bin?
     Maybe some other versions are earlier in your PATH?
     Type type pbpaste to find out where the one you are running actually lives.
     If you are not running the ones from /usr/bin, then try the ones from there (by giving the whole path in your shell commands; e.g. /usr/bin/pbpaste instead of just pbpaste).
   • Is your /usr/bin/pbpaste the correct version for your OS release?
     This can be difficult to determine. See below.
   • Not many other “tty mode” programs access the pasteboard, but if you are familiar with Vim, then you might try MacVim (or some other build of Vim 7.3; e.g. from MacPorts).
     In Vim 7.3 the * and + registers use the pasteboard even when not running in GUI mode (e.g. rename the mvim script that comes with MacVim to just vim and run it inside a Terminal window).
2. If your previous ./test runs were done inside tmux: Try those ./test commands in a plain Terminal window to avoid tmux for the moment.
   The daemon=sys part executes the action that tmux takes that usually causes the problem for programs running inside tmux.
3. Where did your tmux binary come from? Is it possible that it is some kind of patched version that is causing some additional problem?

---

Verifying System-Installed Files

I think Pacifist can verify system files against their receipts, but I have never used it.

Here is how I would do it from the command line:

If¹ you have the “receipts” for your OS installation and updates, then you can extract the expected checksums for pbpaste and pbcopy with this command:
¹ These receipts should usually be present, but I have a vague memory that some third-party “system cleanup” programs delete the receipts.

find /Library/Receipts /var/db/receipts \
  -name \*.bom \
  -exec sh -c 'for f; do lsbom "$f" |
      awk -v F="$f" "/pbpaste|pbcopy/{if(F)print F;F=\"\";print}"; done' \
    0 {} +

(/Library/Receipts is used in 10.4, and /var/db/receipts is used in 10.6; I am not sure which one 10.5 uses, you will see a find: /path: No such file or directory message if one of them does not exist on your system.)

On a 10.6 system, I get this output:

/var/db/receipts/com.apple.pkg.BSD.bom
./usr/bin/pbcopy    100755  0/0 72016   1465783998
./usr/bin/pbpaste   100755  0/0 72016   25541152
./usr/share/man/man1/pbcopy.1   100644  0/0 3025    4025969813
./usr/share/man/man1/pbpaste.1  100644  0/0 18  536112003
/var/db/receipts/com.apple.pkg.update.os.10.6.5.combo.bom
./usr/bin/pbcopy    100755  0/0 72016   2435649573
./usr/bin/pbpaste   100755  0/0 72016   832584555

From this, I can see that pbpaste was installed as part of the com.apple.pkg.BSD package. It was later updated by the 10.6.5 combo system update. The last two numbers are the size of the file and a checksum. You can verify the size with ls -l, but the checksum is not quite as straight forward. Here is how you can generate and dump a BOM based on your existing files:

mkdir /tmp/pb && cp /usr/bin/pbpaste /usr/bin/pbcopy /tmp/pb &&
  mkbom /tmp/pb /tmp/pb.bom && lsbom /tmp/pb.bom

What you want to look for is that the last two columns are identical from the receipts output. Here is the output from the same 10.6 system:

.   40755   506/0
./pbcopy    100755  506/0   72016   2435649573
./pbpaste   100755  506/0   72016   832584555

The middle column is different because my user owns the copies of the files instead of root, but the last two columns match the ones from the 10.6.5 combo updater receipt.

[bmihelac]

1.1 pbcopy is working fine in "plain" terminal window, also in the vim running from terminal window.

1.2. Both pbcopy and pbpaste are in /usr/bin:

$ which pbcopy
/usr/bin/pbcopy

1.3 This is the output that I got:

 $ find /Library/Receipts /var/db/receipts \
 >   -name \*.bom \
 >   -exec sh -c 'for f; do lsbom "$f" |
 >       awk -v F="$f" "/pbpaste|pbcopy/{if(F)print F;F=\"\";print}"; done' \
 >     0 {} +
 find: /var/db/receipts: No such file or directory
 /Library/Receipts/boms/com.apple.pkg.BSD.bom
 ./usr/bin/pbcopy    100555  0/0 55264   392921465
 ./usr/bin/pbpaste   100555  0/0 55264   3634453627
 ./usr/share/man/man1/pbcopy.1   100644  0/0 2297    2973390854
 ./usr/share/man/man1/pbpaste.1  100644  0/0 18  536112003
 /Library/Receipts/BSD.pkg/Contents/Archive.bom
 ./usr/bin/pbcopy    100555  0/0 46772   3861036333
 ./usr/bin/pbpaste   100555  0/0 46772   3861036333
 ./usr/share/man/man1/pbcopy.1   100644  0/0 2297    2973390854
 ./usr/share/man/man1/pbpaste.1  100644  0/0 18  536112003

 mkdir /tmp/pb && cp /usr/bin/pbpaste /usr/bin/pbcopy /tmp/pb &&
>   mkbom /tmp/pb /tmp/pb.bom && lsbom /tmp/pb.bom
.   40755   501/0
./pbcopy    100555  501/0   55264   392921465
./pbpaste   100555  501/0   55264   3634453627

1.4. I am using MacVim version, in plain terminal system clipboard does work

1. I tried both under tmux and without tmux. Both results where equal.
2. I installed tmux with brew, I believe there is nothing special in the recipe:

https://github.com/mxcl/homebrew/blob/master/Library/Formula/tmux.rb

Thanks again for your help. Maybe it is worth to notice that under screen I can't use clipboard as well (and as I remember well screen should be patched by Apple). I start to suspect that it sometimes maybe worked but some change in recent osx upgrade prevent this from working.

[ChrisJohnsen]

Thanks for verifying the fundamentals. Everything looks reasonable:

• Your copies of pbpaste and pbcopy seem to be what the receipts expect (system installed versions are intact).
• They work correctly if they are not run under tmux.
• MacVim in tty-mode can also access the pasteboard if it is not run under tmux.
• Your tmux seems like it is a “stock version”.

It does seem odd that you can not use the pasteboard inside the Apple-supplied screen though (/usr/bin/screen, right?). The reattach-to-user-namespace wrapper program was developed specifically around the technique Apple applied in their Leopard patch to screen, and it works under 10.6 (and 10.7, I am told). Like I said, I have never had a 10.5 system, but there is every reason to think that it should work on Leopard (since it was adapted from Apple-supplied, Leopard-targeted code).

The fact that ./test daemon=sys system=pbpaste fails in a non-tmux environment seems to strongly indicate that the inability to access the pasteboard is still coming from the “usual” location: the system-supplied daemon(3) library function. It is provided in libSystem, which is (mostly) derived from Libc. Apple has published four versions of the Libc code between 10.5 and 10.5.8 (pull up all the 10.5 links at www.opensource.apple.com and search for Libc), but the implementation of daemon(3) is identical in all of them (1, 2, 3, 4). The problematic bit is (at least on 10.6, and 10.7) the move_to_root_bootstrap function. The test program includes an alternate version of daemon(3) that basically just skips the problematic part.

So, here is another experiment (to be run outside of tmux):

./test daemon=ours system=pbpaste
./test daemon=ours move-to-user=10.5 system=pbpaste

The first one should work since it avoids the problematic bit of daemon(3). If the second one fails, then it at least tells us that the call to _vprocmgr_move_subset_to_user is doing something, but still not why it does not work like I expected.

Looking at the 10.5 launchctl(8) manpage indicates that it supports the bslist command. You could use this to confirm that the underlying issue is a bootstrap namespace issue.

You should seen an entry for the pasteboard service when you run the command outside of tmux.

launchctl bslist | grep -i pasteboard

When you emulate running it inside of tmux (or actually run in inside tmux), the service should no longer be accessible:

./test daemon=sys system='launchctl bslist | grep -i pasteboard'

You will probably see a reported exit code of 1 (because grep did not find any matching lines).

You might as well try it with the post-daemon(3) call to _vprocmgr_move_subset_to_user, too (it will probably be the same as without it: no accessible pasteboard service):

./test daemon=sys move-to-user=10.5 system='launchctl bslist | grep -i pasteboard'

You could also try it without any daemon(3) call to see if _vprocmgr_move_subset_to_user is “damaging” the bootstrap namespace binding on its own:

./test move-to-user=10.5 system='launchctl bslist | grep -i pasteboard'

The _vprocmgr_move_subset_to_user function is implemented in the launchd source, but it is provided in libSystem. Apple has released seven versions of 10.5 launchd code, but _vprocmgr_move_subset_to_user was not changed in any of them (launchd/src/libvproc.c versions: 1, 2, 3, 4, 5, 6, 7).

It seems that Apple only every released one version of screen for Leopard: 10.5 through 10.5.8 all use screen-12.

So, overall, there are no good leads at to what might have changed between Leopard releases that might have caused a change in this behavior.

Okay, one more shot in the dark: Can you create a fresh user on the system, login to that user through the GUI (i.e. the normal OS login screen), and try some of this stuff under that user? Maybe some bit of user-specific configuration is keeping it from working. This seems unlikely, but it is a fairly easy thing to eliminate.

[bmihelac]

Here are outputs from commands above:

$ ./test daemon=ours system=pbpaste
$ ./test daemon=ours system=pbpastesystem(pbpaste) process exited 0
$  ./test daemon=ours move-to-user=10.5 system=pbpaste
$ system(pbpaste) process exited 1

$ launchctl bslist | grep -i pasteboard
A  com.apple.pasteboard.666
A  com.apple.pasteboard.1
$ ./test daemon=sys system='launchctl bslist | grep -i pasteboard'
$ system(launchctl bslist | grep -i pasteboard) process exited 1

$ ./test move-to-user=10.5 system='launchctl bslist | grep -i pasteboard'
system(launchctl bslist | grep -i pasteboard) process exited 1

I am going to create new user now to test with fresh settings. By the way I didn't reinsatll screen (as far as I know), version is:

$ which screen
/usr/bin/screen
$ screen --version
Screen version 4.00.03 (FAU) 23-Oct-06

[bmihelac]

I just tested another osx 10.5.8 machine, this one is clean from 3rd party libraries (such as macports, etc.).
Also, it does not have tmux or pasteboard installed.

When I started screen, pbcopy did not work, while outside the screen it worked as expected.

That leads me to think that osx 10.5.8 or some earlier update changed something in the way that broke their own patch around problem and it does not allow your workaround to be working.

[ChrisJohnsen]

Since daemon=ours seems to retain access to the pasteboard it should be possible to patch tmux to use a custom daemon function instead of the system-supplied one. This may help, but it may not fully solve the problem. My guess is that it would let you use the pasteboard from inside such a patched tmux, but only until you logout of the GUI (i.e. any tmux sessions you left running would lose access to the pasteboard when you logged out of the GUI).

It is a bit odd that ./test daemon=ours move-to-user=10.5 system=… and ./test move-to-user=10.5 system=… cause the pasteboard to become inaccessible; those operations are innocuous on 10.6.

The screen version numbers you reported match those in the source code Apple published for its 10.5 screen, so it is probably “stock”. You could check it against the receipts if you wanted extra assurance, though.

It is unfortunate that the system-supplied screen does not work; it was probably the best hope for finding a workaround.

I am out of ideas for now. I’ll keep the situation in mind though, maybe I’ll think of something else to test or try.

[bmihelac]

Have filled issue report on Apple website.
Issue number is #10449159. maybe they can answer since it is screen issue as well.

Thanks once more for your work.