🏝️ 🕗 💎 21世紀コンソール：mosh、tmux、fish 😥 🎼 👨🏻‍⚖️

私の仕事では、ローカルとリモートの両方で、ほとんどすべての時間をコンソールで過ごす必要があります。いいえ、あなたは文句を言いませんが、コンソールツールが提供する自動化機能が気に入っています。コンソールでの作業は非常に生産的です。

ただし、ツールの作業に最大80％を費やしている場合は、時間を無駄にせず、作業が喜びをもたらすことを確認することをお勧めします。この記事では、私が個人的に毎日使用しているツールと、コンソール、特にリモートサーバーを操作する際にユーザーエクスペリエンス（および多くの場合、生産性）を向上させる方法について少しお話したいと思います。

SSHの問題

sshを介してリモートサーバーを操作する場合、イライラする可能性のあるものが多数ありますが、主に2つの問題があり、最初の問題はsshで根本的に解決できません。

往復遅延が長い（> 100ミリ秒）と、ユーザー入力は顕著な遅延で表示されます。モバイルインターネットをエッジ（待ち時間1000ミリ秒）で使用すると、仕事は拷問のようになります。
パケットの配信で一時的な問題（数分）が発生した場合、書き込みが失敗して接続が切断される可能性があります：パイプが切断されます。

ssh by-designは単なるバイトのトランスポートであり、既存のアプリケーションはこの動作に依存しているため、最初の問題は解決できません。 sshはこのバイトストリームを解釈しようとしないため、予測入力を実行できません。個人的には、この問題は最も関連性があります。ヨーロッパとアメリカのサーバーで作業する必要があるためです。2番目のケースでは、遅延は約200ミリ秒であり、少なくとも量子通信またはそのようなものが発明されるまでは根本的に回復できません。私たちの状況では2番目の問題は比較的まれですが、ネットワーク障害が発生した場合にすべての接続を再確立するのは不快です（何らかの理由で画面で起動しなかった場合は、ドロップしたアプリケーションを再起動します）

解決策-mosh（モバイルシェル）

上記の問題の解決策は非常に急進的です-mosh （ mosh.mit.edu ）は、UDPで動作し、「そのまま」バイトを転送するSSHで使用されるアプローチの代わりに画面差分を送信する別個のクライアントサーバーシステムです。最初の接続はsshを介して行われますが、sshはmosh-serverのみを開始し、その後終了します。このため、moshを使用してサーバーに接続するには、SSHを使用するよりも少し時間がかかります。

sshではなくmoshを使用するには、コンピューターにmoshクライアントをインストールし、リモートホストにmosh-serverをインストールする必要があります。一般に、システム全体にインストールする必要はありません-デーモンはユーザーとして機能し、接続時にサーバーバイナリを指定できます（例：mosh --server / home / yuriy / bin / mosh-server my-server-hostname）。

moshはudpを介して画面の差分を送信するため、tcp / ipを介した通常のsshとは性質が大きく異なります。

接続が切断されることはありません

「接続」はありません。ネットワーク接続が復元されると、コンソールの現在の状態が再び表示され始めます。サーバーへの接続方法を変更することもできます。たとえば、wi-fiアクセスポイントを変更すると、すべてが引き続き機能します。これは、不安定性のモデルであるモバイルインターネットでVPNを使用する場合に特に便利です。

マウスホイールでストーリーをスクロールする機能は忘れてください

moshはすべてを別の画面に描画し、残りを送信せずに前の状態との違いのみを表示するため、ローカルスクロールは機能しません。ストーリーを少なくともどこかに保存するには、screenまたはtmuxを使用する必要があります。これについては後で説明します。いくつかのファイルを使用して、マウスホイールを機能させることはできますが、感覚は依然として「間違っています」。

高遅延では、予測エコーが有効になります

たとえば、EDGEを介してSSHを使用する場合、私は本当にあなたをen望しません:)。この場合、moshは現在動作しているコンテキストで「理解」でき、ほとんどの場合、少なくともサーバーから何かが来る前であっても入力を適切に表示できます。次の図では、「下線付き」テキストはユーザーが入力したテキストですが、サーバーからのエコー（ほとんどの場合、ユーザーが入力したテキストのみ）はまだ受信されていません。また、レイテンシが高すぎない場合（たとえば、50ミリ秒、すでに目で確認できる場合）でも、moshは入力されたテキストがサーバーから単に返される瞬間を「確信」している場合、即座にユーザー入力を表示しようとします。したがって、50〜100ミリ秒程度のレイテンシの場合、リモートコンソールでの作業はローカルの作業とほとんど区別できなくなります。上記のように、ストーリーを見る機会を除きます。

これらすべては、サーバーがコンソールからの出力も「レンダリング」し、画面の現在の状態をメモリに保持するという事実により実現されます。 moshのトラッカーには、履歴も保存できるようにするための提案があります。したがって、screen / tmuxの形式で追加のレイヤーを拒否できますが、これまでのところ、著者はこの方向で何もしていません。

tmuxとは何か、なぜスクリーンよりも優れているのかを見ていきましょう。

画面の問題

残念ながら、私は画面の専門家ではないので、問題を2つだけ挙げることができます-画面を垂直に分割するためのサポートの欠如（デフォルトでは水平の代わりに）と非常に古いコードベースのために一般的に遅い開発画面の使いやすさも望まれていませんでした。画面4.2の新しいバージョンでは垂直方向の分離のサポートが記録されていましたが、その時までに私はすでにそれを使用していませんでした。一般に、sshと同様、screenは依然として事実上の標準であり、割引することはできません。

tmuxと画面上の利点

端末マルチプレクサ（Terminal MUltipleXor）のことを聞いたことがない場合は、前の段落がわかりにくい可能性があります。したがって、それが何であるかについて少しお話しします。

sshで長時間実行される操作を開始したいが、接続が切断される状況を想像してください。または、このコマンドは「trueの間」なので、完了するのを待ちたくありません。実行デーモンを実行します。完了しました。」デフォルトでは、対話型セッションは、切断されるとこのセッションからすべてのプロセスにSIGHUPシグナルを送信し、プロセスは終了します。

この問題はさまざまな方法で解決できます。たとえば、nohupコマンドを使用して、出力をファイルにリダイレクトし、SIGHUPを無視します。しかし、より興味深い解決策は、screenやtmuxなどの端末マルチプレクサを使用することです。通常、最初の開始時に新しいセッションが開始され、そこで作業を行うことができます。このセッションは、ssh接続と密接に結びついていません。たとえば、ssh-connectionでタブを閉じるか、「Ctrl + BD」を押す（つまり、最初にCtrl + Bを押し、次にCtrlを放してDを押す）と切断できます。tmux内で実行されているすべてのアプリケーションは変更されません。次に、「tmux attach」または「-rD」などのフラグを含む画面を入力して、このセッションに再接続できます。

一般に、tmuxはよりユーザーフレンドリーに見え、すぐに使用できる非常に興味深いものをサポートします。

上記の例では、たとえばCtrl + B：split-verticalを使用して、画面を垂直に分割します。残念ながら、このような分割画面をサポートする新しいバージョンの画面は、まだどこでも見つかりません。
既存のセッションに数回接続する機能-tmux attachは、他の接続ユーザーを「スロー」せずに既存のセッションに接続します
オプションでマウスモードを設定して、マウスホイールで履歴を巻き戻す
sudoを介して別のユーザーの画面に接続しようとするときに「スクリプト」を実行する必要はありません

ほとんどの場合、上記のすべてのことは画面のフレームワーク内で行うことができます。tmuxはもともとユーザーにとってよりシンプルになるように設計されており、より多くの機能を備えています。突然iterm2を使用する場合は、tmuxとの統合のサポートが組み込まれていますが、これも賛成の議論になります。

そして最後に、魚について話しましょう-フレンドリーなインタラクティブシェル

bashの欠点

正直なところ、bashがどんな威厳を持っているかを言うのは難しいです。 bashの最大の利点は、最も一般的なシェルであり、ほとんどのLinuxディストリビューション、mac os x、さらにはcygwinにもデフォルトでインストールされることです。また、bashはposix互換です。つまり、システム上で/ bin / shを/ bin / bashに置き換えることができ、「何も壊れません」。ただし、bashのインタラクティブな機能は、zshの人の別の一般的な競合他社よりはるかに遅れており、bashには正しいプロンプトさえありません。 bashとzshの両方のほとんどの機能はデフォルトでオフになっています。これらのシェルのすべての機能を利用するには、セットアップにかなりの時間を費やすか、たとえばoh-my-zshなどの既製のソリューションを使用する必要があります。

21世紀のインタラクティブシェル-魚

fish（使いやすいインタラクティブシェル）がどのように機能するかを一度確認すれば十分です。他のものは使いたくないでしょう:)。一般に、fishはPOSIX互換ではなく、単なる対話型のシェルです。つまり、/ bin / shまたは/ bin / bash用に記述されたスクリプトは、それを使用して実行できません。シェルの構文は通常と少し異なります。以下の例を参照してください。

主な機能：

入力したとおりの履歴からのコマンドおよびファイル名のリアルタイムでの自動補完
「バッテリー付き」-箱から出してすぐに、ほとんどのチームにスマートな自動アドオンがあり、git_promptなどがあります。
左右のプロンプトの存在、それらのサイズの正しい計算、プロンプトはPS1からの行ではなく関数によって設定されます
ディレクトリの自動履歴-Alt + Shift +左右矢印を使用すると、透過的に前のディレクトリに戻って戻ることができます
「修正された」構文は、fi、esac、$？、backtics（ `cmd`）およびその他の多くのこと-適切なヒントがあります-これにより、魚は非POSIXシェルになります。これは一般に美徳ではありませんは
略語のサポート-たとえば、略語「st-> git status」を作成することにより、「st」を入力するとすぐに「git status」を「入力」します-このように自動補完が機能し、あなたの周りの人は理解できない略語を恐れません
<tab>による自動補完の改善-ヒントそのものだけでなく、そのタイプも表示されます（たとえば、ブランチとタグはgit checkoutで別々に表示されます）

また、わずかな改善点もあります。

プログラムの出力が改行で終わっていなくても、プロンプトは正常に表示され、劣化しません。
ファイルへの正しいパスに下線を引く
間違ったコマンドを赤で表示-Enterキーを押さずに間違ったコマンド名を入力したことがわかります。
2> |の形式の構文を使用してstderrをパイプに簡単にリダイレクトする機能または^ |
すべてが関数であり、エイリアスはありません。関数の自動ロードはサポートされています-fishをロードしても使用可能なすべての関数がメモリに読み込まれるわけではなく、完全な設定を再読み込みせずにその場で関数コードを変更できます
ローカル変数CMD_DURATION-最後のコマンドの実行時間（ミリ秒）
デフォルトで現在のディレクトリへの短縮パス-最後のディレクトリを除き、パスの各コンポーネントの最初の文字が使用されます（たとえば、/ usr / local / bin /-> / u / l / bin /）

CMD_DURATIONとgit_promptを使用した正しいプロンプトの例：

$ cat ~/.config/fish/functions/fish_right_prompt.fish function fish_right_prompt if test $status = 0 echo -n (set_color green) else echo -n (set_color red) end echo $CMD_DURATION (set_color normal)ms (set_color yellow) (__fish_git_prompt "%s") (set_color normal) end

if-expressionsの構文に注意してください。シェルよりもPythonに似ています。括弧内の式は「コマンドの結果を挿入する」ことを意味します-bashでは$（...）として記述され、魚では最初のドル記号は必要ありません。

これは次のようなものです。

右側のプロンプトには、コマンドの実行時間がミリ秒単位で表示され、コマンドが成功した場合は緑色、エラーが発生した場合は赤色で表示されます。現在のブランチがある場合は、黄色で表示されます。

mosh、tmux、fishの統合、結論

tmuxとfishを一緒に使用すると、2つの問題が発生する可能性があります。どちらも少し不快ですが、簡単に解決できます。

stderrからの出力「消える」 -github.com/fish-shell/fish-shell/issues/2115-は、単に「fish」ではなく「fish 2>＆1」を実行することで解決されます。

デフォルトでは、tmuxは$ TERM環境変数をscreenに設定しますが、256色モードをサポートしているため、16色モードでフォールバックする代わりに通常の魚を取得するには、「export TERM = screen-256color」環境変数を設定する必要があります

また、魚で右プロンプトを使用する場合、およびtmuxでウィンドウを垂直に分割する場合、moshのクライアントは高速入力中に右境界線をシフトし始める可能性があり、描画時に一時的なアーティファクトにつながります。これは、moshがtmuxのパネルを区切るフレームの位置、および魚の右プロンプトの位置が固定されていることを理解していないため、残りのテキストとともに右に入力するときにそれらをシフトします。

合計：上記のすべてのツールは非常に新しく、通常のssh + screen + bashバンドルと同じ状態にはまだ磨かれていませんが、時間が経つにつれて開発者はユーザーからのフィードバックを考慮し、他の「新しい」ツールとの統合を改善します。

一般に、mosh + tmux + fishバンドルは、多くの新しいものを作成せずに、リモートコンソールでの作業に関連する小さな（そしてそうではない）多くの問題を解決しました。説明した各ツールの多数の小さいながらも便利で便利な機能は、自分で試してみる価値があるように思えます。

21世紀コンソール：mosh、tmux、fish