はじめに
実装の話はありません。今日こちらの投稿をみて、おお凄い！と思う反面、今の自分はあまり使わなそうだなぁとも思いました。
コマンド入力一撃で端末を大量に分割してタスクを瞬殺するtmux-xpanes
http://qiita.com/greymd/items/8744d1c4b0b2b3004147
実は自分も昔はtmuxの画面分割をこよなく愛し、自作の画面分割スクリプトも作ったりはしていたのですが、最近全く使わなくなっている自分がいました。
良いタイミングなので、それはなぜだろうと改めて文書化して理由を書き起こしてみました。
マルチプレクサーの強み
自分が考えるtmuxやscreenといったターミナルマルチプレクサの強みは、 リモートサーバでバーチャルコンソールを立ち上げて、色々動かせることかなと感じています。
直接ttyで操作するのではなく、バーチャル経由で動かすことによって、より簡単に他のメンバーにも画面を共有したり、一旦作業をやめて家からまた作業をやり直したり、もちろん画面分割なども簡単に出来るようになります。
運用するときも結構便利で、Railsなど運用していると、Rakeタスク実行のためにとりあえず1台のマシンに入る、、なんてこともあると思います。そのリモートのサーバで、割と処理時間の掛かりそうな Rakeタスク などを動かしたい場合に、いちいち nohup にしてバックグラウンド起動させなくても、1枚tmuxを入れているだけで、フォアグラウンドでそのまま実行しても、画面をデタッチすればいつでも抜けることも出来ます。 再度アタッチすればいつでも作業の状況を見ることが出来ます。 bg や fg コマンドを使って混乱することもありません。
「tmuxは再起動するとセッションが全部消えてしまうのが好きじゃない」という話はよくあったりしますが、そもそもリモートのサーバ上で動かすことを前提にしたプロダクトなのではないかなと自分は解釈しています。
カスタム設定ファイルをリモート環境を汚さずに読み込む
リモートでtmuxを立ち上げるとなると、問題なのはカスタム設定です。デフォルトのキーバインドは案外使いにくかったりするので、カスタムすることも多いと思うのですが、その設定はポータブルに持っていきたいものです。
リモート環境の .tmux.conf に勝手に設置して、「俺の設定をみんな使え！！ガハハ」のような訳にもいかないと思いますので、自分はこのような1行をスグに引っ張れるようにしています。
curl https://raw.githubusercontent.com/shimma/dotfiles/master/.tmux.conf >/tmp/f && tmux -f /tmp/f new
tmuxでは -f オプションを利用することにより、設定ファイルを個別にロード可能です。本来であれば、tmux 自体がURLあたりをそのまま設定ファイルの引数に渡せられれば楽ちんなのですが、そうもいかないので、このようになっています。
これによって、自分の手に馴染んだ方法で、リモート先でも操作することが出来ます。
沢山のマシンに1箇所からSSHするケースがあるか
10台くらいのリモートマシンに対して、インストールしたりする作業をするから SSH を個別にする！という用途もありそうな気もします。
ただし、そこまで台数があれば、ちゃんと構成管理をして Chef/Ansible などより作業する必要があり、ガチャガチャっと手元からやるケースも少ない（少なくなってきた）と個人的には感じます。ある程度台数が増えてきたら、個別に SSH も限界がありそうな感じもします。
とはいえ何か障害が起きた土壇場で、tmux を使ってばばっと画面を出して、縦横無尽に検証していくというシーンも割とあったりするので、完全に消えることもなかったりはしますが。。
なんでもfuzzy search、かっちり管理しない
Rails開発することは多く、ご存知の通り、rails console であったり log であったりお決まりのセットはあります。そういった背景もあり tmuxinator という tmux のペインとウインドウを yaml で管理するツールが生まれたと思うのですが、最近はIntelliJ の画面で色々出来てしまったり、そもそも画面が欲しい時に、毎回 zsh のヒストリーから適当にコマンドを拾ってくるようになりました。
ヒストリー系は何でも peco とシェルを連携させたり、とにかく何でも fuzzy サーチ出来るような環境を用意しています。
peco-select-history() {
local tac
if which tac > /dev/null; then
tac="tac"
else
tac="tail -r"
fi
BUFFER=$(history -n 1 | \
eval $tac | \
peco --query "$LBUFFER")
CURSOR=$#BUFFER
zle clear-screen
}
zle -N peco-select-history
bindkey '^r' peco-select-history
## どこかから拝借したものをzsh上で活用しております mm
neovimであれば、denite.nvim、IntelliJであればデフォルトのCommand + Shift + Oは愛用です。とにかく断片しかコマンドを覚えなくなってきているので、脳が退化しているのではないかと心配もあります。。
これに関してはしっかりtmuxinatorのようなツールを使い直したほうがいいかもしれません。
ターミナルの画面分割論
自分の最近のブームはiTermの画面分割とtmuxの画面分割を両方使うことです。
| iTerm | tmux | |
|---|---|---|
| マウススクロール | ◎ | △ (機能としてはあるが) |
| ペインの操作 | △ | ◎ (サイズ変更やZoomなども楽々) |
| リモートでの画面分割 | ✕ | ◎ (そもそもリモートで立ち上げる） |
tailf などが必要なものはiTermで画面分割して、マウススクロールを使えるようにしますし、わりとちょこまかPane操作が必要であればtmux経由で動かします。
iTerm/tmux 画面分割両刀使いのオススメ設定
余談ですが、あまり使っている人を見たことないのですが、iTermのタブを縦に表示するのが地味に便利でおすすめです。
tmuxのウインドウ一覧が横で、iTermのウインドウ一覧が縦のようになると見やすいためです。
基本的にiTermの1タブが1接続先なイメージです。 iTermの1タブはとあるリモートサーバ専用で、SSHしたリモート先で tmux を立ち上げ沢山 pane を分割し管理して動かしています。とはいえ、もちろん手元でカチャカチャっとリモートにSSHするケースもあるので、厳密にやっている訳でもないですが。。
終わりに
開発環境それぞれで、全ての方法がマッチするとは限りません。ただ、昔tmuxを使っていた時代とだいぶ付き合い方も変わってきているなぁと思い記事にしてみました。
「自分はこんな風に使うぜ」 など向き合い方にフォーカスした記事はあまり見かけないと思うので、ぜひ他の方のコメントも見てみたい所です。ぜひコメントあればお待ちしております。