Em todas as configurações do Ubuntu 12.04 meus comandos de copiar e colar da área de transferência tmux são configurados da seguinte forma:
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"
Isso funcionou muito bem por mais tempo até um mês ou mais atrás, quando suspeito que alguma alteração de configuração ou alteração de pacote tenha sido feita e que tenha quebrado o acima. No terminal GNOME, a colagem ainda funciona bem com o prefixo + ctrl-v e ctrl-shift-v .
No entanto, o comando xclip copy não funciona mais, não importa o que eu faça, e tentei remover a ligação de prefixo personalizado acima, usando -select em vez de -sel , não usando clipboard etc. muito um show stopper para um usuário do GVim como eu, já que eu nem tenho a solução de terminal do GNOME de ctrl-shift-c com o tmux assumindo o shell. Entro em modo de cópia, seleciono texto com espaço + movimento , e quando executo prefixo + ctrl-c absolutamente nada acontece. Antes disso, o tmux mostrava uma mensagem de confirmação na seção de notificação na parte inferior.
Alguém tem sugestões sobre como alguém pode depurar isso? Este é um grande sucesso de produtividade. Provavelmente, posso usar o truque de solução temporária de arquivos por enquanto , mas seria ótimo saber exatamente o que aconteceu com xclip .
O utilitário xsel é semelhante a xclip , mas implementado de forma um pouco diferente. Normalmente eu esperaria que eles se comportassem da mesma maneira, mas eles não fazem exatamente a mesma chamada de biblioteca X, então é possível que em alguns casos de canto xsel funcione mas não xclip , ou vice-versa. Experimente:
bind C-c run "tmux save-buffer - | xsel -ib"
bind C-v run "tmux set-buffer \"$(xsel -ob)\"; tmux paste-buffer"
A adição do comando -b to run-shell (ou run ) corrigiu o problema. Com -b , o comando shell é executado em segundo plano.
bind C-c run-shell -b "tmux save-buffer - | xclip -i -sel clipboard"
Embora eu não consiga mais reproduzi-lo, mas aqui está a resposta técnica do que poderia ter acontecido no seu caso.
Primeiro, você precisa entender como a área de transferência do X11 funciona. Você pode ler o ensaio de jwz sobre isso: link
Em suma, o aplicativo que contém o conteúdo da área de transferência precisa ser executado até que outro aplicativo declare a propriedade. Portanto, quando você executar xclip -i <<< test , poderá ver o xclip sendo executado em segundo plano até fazer outra seleção:
$ 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
Agora está tudo bem, mas quando você sai desse shell, todos os processos pertencentes a esta sessão são mortos por padrão enviando um sinal HUP. Isso significa que o xclip será eliminado e você não poderá mais acessar o conteúdo da sua área de transferência.
Portanto, a solução sugerida (no caso de você não ter xsel) é ignorar o sinal HUP usando a seguinte ligação:
bind C-c run "tmux save-buffer - | nohup >/dev/null 2>/dev/null xclip -i -sel clipboard"
xsel não é afetado por este problema porque a primeira coisa que ele faz após o fork () é se desassociar do terminal de controle para não receber o sinal HUP quando o shell sair (você não vê-lo na saída de ps acima, mas apenas quando você faz um ps -e | grep xsel ).
Estou com um problema semelhante e o arquivo temporário não ajudará neste caso em particular, receio. Isso ocorre porque xclip parece se comportar de maneira diferente quando gerado pelo tmux do que quando está sendo executado "interativamente" e espera que outro aplicativo assuma a propriedade da área da área de transferência. Tente usar xclip -l 1 para sair imediatamente (veja man page para detalhes).
Esta é uma pergunta antiga, mas suspeito que tenha a solução, tirada da página do Tmux do wiki do Arch :
xclip could also be used for that purpose, unlike xsel it works better on printing raw bitstream that doesn't fit the current locale. Nevertheless, it is neater to use xsel instead of xclip, because xclip does not close STDOUT after it has read from tmux's buffer. As such, tmux doesn't know that the copy task has completed, and continues to wait for xclip's termination, thereby rendering tmux unresponsive. A workaround is to redirect STDOUT of xclip to /dev/null
Assim, seu comando deve se tornar:
bind C-c run "tmux save-buffer - | xclip -i -sel clipboard >/dev/null"
Esta é uma configuração de trabalho que uso:
# 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