macOS 'reattach-to-user-namespace' wrapper no longer required in tmux 2.6

[benjaminblack]

See: ChrisJohnsen/tmux-MacOSX-pasteboard#66

Try, e.g., bind-key -T copy-mode C-\ send-keys -X copy-pipe-and-cancel "pbcopy"

[karismatic-megafauna]

I am still getting this error in whenever I make a new split.

Could this line be the culprit?
https://github.com/tmux-plugins/tmux-sensible/blob/master/sensible.tmux#L97

[astahlman]

@karismatic-megafauna FWIW, I too was seeing this message upon opening a new split and originally suspected that line. However, I ruled it out as the cause of the error after I started tmux with an empty config and still saw the same error: tmux -f /dev/null.

Updating reattach-to-user-namespace via homebrew eventually fixed it for me: brew update && brew upgrade reattach-to-user-namespace

[dannykansas]

Updating to the latest reattach-to-user-namespace resolved this issue for me as well.

Would it be possible to offer a more useful error message through tmux, e.g. suggesting an update to reattach-to-user-namespace?

For reference, the version that resolves this issue is:

$ reattach-to-user-namespace --version
reattach-to-user-namespace version 2.8
    Supported OSes: OS X 10.5-10.15

[xukai92]

I'm not sure if this is the best place to mention this, but the current work-around for reattach-to-user-namespace, i.e. below

if is_osx && command_exists "reattach-to-user-namespace" && option_value_not_changed "default-command" ""; then
	tmux set-option -g default-command "reattach-to-user-namespace -l $SHELL"
fi

causes some of commands I put in the end of my shell init file (pfetch) to run twice.

It seems that removing this work-around doesn't hurt anything (e.g. tmux-yank still works).