Mu Ubuntu 12.04のセットアップでは、tmuxクリップボードのコピーアンドペーストコマンドは次のようにセットアップされます。
set -g prefix M-a
unbind C-b
bind C-c run "tmux save-buffer - | xclip -i -sel clipboard"
bind C-v run "tmux set-buffer \"$(xclip -o -sel clipboard)\"; tmux paste-buffer"
これは、上記を破った構成変更またはパッケージ変更が行われたと思われる1か月ほど前まで、最も長い間うまく機能しました。 GNOME端末では、貼り付けは両方とも正常に機能します prefix+ctrl-v そして ctrl-shift-v。
ただし、xclip
コピーコマンドは何をしても機能しなくなり、上記のカスタムプレフィックスバインディングを削除しようとしました。-select
の代わりに-sel
を使用し、clipboard
など。GNOMEターミナルの回避策すら持っていないので、これは私のようなGVimユーザーにとってはほとんどショーストッパーです。 ctrl-shift-c tmuxがシェルを引き継ぎます。コピーモードに入り、テキストを選択します space+movement、そして私が実行するとき prefix+ctrl-c 絶対に何も起こりません。これが壊れる前に、tmuxは下部の通知セクションに確認メッセージを表示していました。
これをどのようにデバッグするかについて、誰か提案がありますか?これはかなり大きな生産性の打撃です。おそらく 今のところ一時ファイルの回避策 を使用できますが、xclip
に何が起こったのかを知るのは素晴らしいことです。
xsel
ユーティリティはxclip
に似ていますが、実装方法が少し異なります。通常、同じように動作することを期待しますが、まったく同じXライブラリ呼び出しを行わないため、場合によってはxsel
は機能するが、xclip
は機能しない可能性があります。またはその逆。試してください:
bind C-c run "tmux save-buffer - | xsel -ib"
bind C-v run "tmux set-buffer \"$(xsel -ob)\"; tmux paste-buffer"
-b
をrun-Shell
(またはrun
)コマンドに追加すると、問題が修正されました。 -b
を使用すると、シェルコマンドがバックグラウンドで実行されます。
bind C-c run-Shell -b "tmux save-buffer - | xclip -i -sel clipboard"
私はもうそれを再現することはできませんが、ここにあなたの場合に起こったかもしれない技術的な答えがあります。
まず、X11クリップボードがどのように機能するかを理解する必要があります。あなたはこれに関するjwzのエッセイを読むかもしれません: http://www.jwz.org/doc/x-cut-and-paste.html
つまり、クリップボードの内容を保持するアプリケーションは、他のアプリケーションが所有権を主張するまで実行する必要があります。したがって、xclip -i <<< test
を実行すると、別の選択を行うまで、バックグラウンドでxclipが実行されていることがわかります。
$ xclip -i <<< test
$ ps
PID TTY TIME CMD
10166 pts/8 00:00:00 xclip
10171 pts/8 00:00:00 ps
19345 pts/8 00:00:00 bash
これで問題はありませんが、このシェルを終了すると、このセッションに属するすべてのプロセスがHUP信号を送信することでデフォルトで強制終了されます。これは、xclipが強制終了され、クリップボードの内容にアクセスできなくなることを意味します。
したがって、推奨される回避策(xselがない場合)は、次のバインドを使用してHUP信号を無視することです。
bind C-c run "tmux save-buffer - | Nohup >/dev/null 2>/dev/null xclip -i -sel clipboard"
xsel
はこの問題の影響を受けません。なぜなら、fork()の後に最初に行うのは、制御端末からの関連付けを解除して、シェルが終了したときにHUP信号を受信しないようにすることです。上記のps出力でそれを参照してください。ただし、ps -e | grep xsel
を実行する場合のみです。
同様の問題が発生しており、この特定のケースでは一時ファイルが役に立たないのではないかと心配しています。これは、xclip
がtmuxによって生成されたときと、「インタラクティブに」実行されたときとでは動作が異なり、別のアプリケーションがクリップボード領域の所有権を取得するのを待つためです。 xclip -l 1
を使用して、すぐに終了するようにしてください(詳細については、manページを参照してください)。
これは古い質問ですが、 Arch wikiのTmuxページ から取得した解決策があると思います。
xclipは、xselとは異なり、現在のロケールに適合しない生のビットストリームを印刷する場合に適しています。それでも、xclipはtmuxのバッファーから読み取った後、STDOUTを閉じないため、xclipの代わりにxselを使用する方が適切です。そのため、tmuxはコピータスクが完了したことを認識せず、xclipの終了を待機し続けるため、tmuxが応答しなくなります。回避策は次のとおりですxclipのSTDOUTを/ dev/nullにリダイレクトします
したがって、コマンドは次のようになります。
bind C-c run "tmux save-buffer - | xclip -i -sel clipboard >/dev/null"
これは私が使用する動作構成です:
# Yank to copy text with y.
bind-key -t vi-copy y copy-pipe "tmux save-buffer - | xclip -sel clipboard -i"
# Update default binding of `Enter` to also copy with this method.
unbind -t vi-copy Enter
bind-key -t vi-copy Enter copy-pipe "tmux save-buffer - | xclip -sel clipboard -i"
# Toggle rectangular copy mode.
bind-key -t vi-copy 'C-v' rectangle-toggle
# Bind ']' to paste.
bind ] run "tmux set-buffer \"$(xclip -o -sel clipboard)\" && tmux paste-buffer"
# Toggle rectangular copy mode.
bind-key -t vi-copy 'C-v' rectangle-toggle
# http://askubuntu.com/a/507215/413683
set -g set-clipboard off