- Starship は、さまざまなシェル環境で使える 軽量・高性能・柔軟性 を備えたプロンプトのオープンソースプロジェクト
- Bash、Zsh、Fish、Powershell、Tcsh など 主要なシェルのほとんど をサポートする幅広い互換性を提供
- 各シェルごとに初期化スクリプトを 簡単に追加 する方式で設定と適用が可能
- Rust で書かれており、高速性と安全性を保証し、単一バイナリとして提供される
- 細かな部分まで自由にカスタマイズ可能
- Android、BSD、Linux、macOS、Windows など多様なプラットフォームで共通の環境構成をサポートし、生産性向上と使いやすさを提供
Starship オープンソースプロジェクト
- Starship は、性能とカスタマイズ性を同時に備えた プロンプトツール であり、さまざまな OS とシェルで利用できる
- 従来の重いプロンプトと比べて 高速な応答速度 と 低いリソース使用量 が特長で、高いカスタマイズ性によって開発生産性の向上に役立つ
各シェル環境での設定方法
- Bash:
~/.bashrc ファイル末尾に eval "$(starship init bash)" コードを追加
- Fish:
~/.config/fish/config.fish ファイル末尾に starship init fish | source を追加
- Zsh:
~/.zshrc ファイル末尾に eval "$(starship init zsh)" コードを追加
- Powershell:
Microsoft.PowerShell_profile.ps1 ファイルに Invoke-Expression (&starship init powershell) を追加
- PowerShell のプロファイルファイルの場所は
$PROFILE 変数で確認可能
- Ion:
~/.config/ion/initrc ファイルに eval $(starship init ion) コードを入力
- Elvish:
- v0.18 以上のバージョンのみ対応
~/.elvish/rc.elv ファイルに eval (starship init elvish) コードを追加
- Tcsh:
~/.tcshrc ファイルに eval \starship init tcsh`` コードを入力
- Nushell:
- v0.96 以上のみ対応、今後設定方法が変更される可能性あり
- 設定ファイルのパスは
$nu.config-path コマンドで確認
- そのパスに
starship init nu | save -f ... コードで適用
- Xonsh:
~/.xonshrc ファイル末尾に execx($(starship init xonsh)) コードを入力
- Cmd(Clink 必要):
- Clink v1.2.30 以上が必要
starship.lua ファイルを作成して Clink のスクリプトディレクトリに保存
- 内部には
load(io.popen('starship init cmd'):read("*a"))() コードを追加
2件のコメント
何年も愛用しているものが取り上げられると、新鮮ですね :)
Zsh テーマとして提供されていた頃から使っていたので……(笑)
Hacker Newsのコメント
私はマキシマリストなプロンプトが好きなユーザーで、開発マシン構築によく Starship を使った Shell Bling Ubuntu インストールを使っている
とはいえ、こういうスタイルが全員に合うわけではない
いちばん密度の高い情報だけを追加したいなら、プロンプトが表示された時刻と最後のコマンドの実行時間だけを出すのがおすすめ
この 2 つの情報があるだけで、何がいつ起きたかを簡単に把握でき、あとでデバッグや記録管理をするときに大きな利点になる
これは Michael W. Lucas の『Networking for System Administrators』から得たコツで、ネットワークの基礎を学びたい開発者にはこの本もよく勧めている
nerd ポイントをもっと稼ぎたいなら、UNIX epoch 基準の秒単位で時刻を表示するとよい
時間差の計算がとても簡単になる利点がある
Shell Bling Ubuntu repo 参照
nushell ではこうした情報が標準で提供されている
履歴ではコマンドの開始タイムスタンプ、実行時間、現在のディレクトリ、終了状態などの詳細情報を確認できる
コマンド実行間の時間差だけでなく、コマンド自体の実行時間も直接見せてくれるのでとても便利
プロンプトをカスタマイズしたことはほとんどない
emacs を使えば欲しい情報はすでにエディタ内で全部見られるからだ
ペアプログラミングのように他人に見せる必要があるときだけ Starship をセットアップし、別のターミナルアプリを開いておけば自分の設定を見せる必要がない
直前のコマンドの exit code(終了コード)も上と似た理由で非常に有用な情報だ
人が読みやすい形式で現在時刻を表示するのもかなり役に立つ
そして前のコマンドの終了状態が 0 以外なら(失敗時なら)表示してくれるとデバッグに役立つ
私には現在のディレクトリ情報だけで十分
最後のコマンドの成功・失敗状態に応じてプロンプトの色だけ変わればよい
追加情報は必要なときに別途確認すればよい
Starship ユーザーの年齢分布データが気になるという興味
自分は時間がたつにつれてプロンプトのカスタマイズにあまり関心がなくなった
どれだけ精巧にプロンプトを飾っても、表示される情報の 90% は 90% の時間では不要だという結論になった
むしろ情報が多すぎると視覚ノイズに感じられ、結局は脳が無視するようになって、その情報があること自体を忘れてしまう
本当に重要な情報をプロンプトだけで表すには限界があり、たとえば Git ブランチが変更されている表示だけではどのファイルが変わったのか分からないので、結局追加のコマンド実行が必要になる
開発歴 20 年超
プロンプトに Git 情報があるのをとても便利に使っている
細かな情報まで分かるわけではないが、コミットしていない変更や忘れていた stash などがあることを思い出させてくれるのでよい
Starship は面白そうだったのでその場でインストールしてみたが、ツールのバージョン表示のような部分はうるさすぎると感じて結局アンインストールした
コマンドのタイミングや成功・失敗状態のようなオプションは良かったが、複雑なカスタム構成を管理する手間のわりに得るものが少なかった
業界 25 年超のシニアとして、派手な最新ツールはあまり使わない方だ
昔は <pre><code>export PS1="[\033[1;32m][\t \u@\h \w]\$[\033[0m]"</code></pre> のように、時刻、自分のアカウント、接続先ホスト、現在のパス程度だけを表示する非常にシンプルな PS1 を使っていた
他の高度なプロンプトも何度も試したが、ほとんど役に立たなかった
今は Starship をここ数年ずっと快適に使っている
必要な情報だけが最小限出るようにカスタムしていて、とても高速で快適
私のプロンプトカスタムで最も有用な部分のひとつは、直前のコマンドの exit status(終了コード)の表示
エラーメッセージが何も出ないままコマンド実行が失敗することがあるので、失敗表示があるのは大きなシグナルになる
ただし、普段はノイズにならないよう失敗したときだけ表示
例: <pre><code>» true » false (last command returned 1.)</code></pre>
signal で終了した場合も翻訳して表示し、「last command exited on SIGSEGV」のように出す
逆に、プログラムがエラーメッセージを出したのに成功コードで終了する場合にも有用
数十年の UNIX 利用経験がある「very senior」ユーザーとして、Starship minimal mode はすっきりしていて好み
以前は何年もいろいろな zsh 設定で苦労したが、今は hassle がほとんどない
Starship ユーザーはみんな JavaScript で emoji を多用する新世代だろうと予想していたなら、私のような人間もいると伝えておきたい
もっと広く見れば、コンピューティング環境全体に当てはまる現象
若い頃は Gentoo で自分で OS を作り、CPU 最適化フラグ、ウィンドウマネージャ、bashrc の alias と関数、プロンプトまで執着して設定することに没頭していた
こうした最適化作業そのものが、成長の過程でかなり役立つ経験になる
木工にたとえるなら、初心者のうちは道具や小技を作ったり磨いたりすることに時間の大半を使うが、ある時点で実作業中心へと集中が移る
今でも Linux は好きだが、忙しい現実では効率や完成度を突き詰めるより「仕事」を優先するので、Debian と KDE の基本環境をそのまま使っている
不要な装飾や情報過多が嫌いなので、ミニマルなターミナル環境を好む
ただ Starship は必要に応じて文脈をうまく見せてくれ、細かくカスタマイズできる
デフォルトのプロンプトは現在のディレクトリ、時刻、そして % だけを表示
特定の環境変数(KUBECONFIG、OS_CLOUD など)が設定されていれば、それに応じた情報も含める
Go、Python などの言語バージョンも使用コンテキストに応じて自動表示
Starship はこうした設定を本当に簡単に実現でき、複雑な zsh プラグイン構成なしで最小限のオーバーヘッドでそのまま動く
とくに evalcache と一緒に使うと初期化速度も非常に速い
Starship ファンとしていくつかコメント
Rust で安全かつ高速に開発されており、ビルド済みバイナリなので、パフォーマンスは Python ベースの powerline、シェルスクリプトベースの ohmybash、zsh ベースの ohmyzsh、spaceship よりずっと良い
zsh、bash、sh、fish 対応はもちろん、MS Windows CMD、Powershell まで対応
単一の config ファイルで全システムのプロンプトを管理できるのはほぼ唯一
情報が多すぎれば簡単に変えられるし、アイコンも無効化できる
約 100 個のモジュールでカスタマイズの限界がほとんどない
Starship を「minimal」だとマーケティングしている理由が理解できない
<pre><code>: ▶</code></pre>実際には非常に多機能で、実際の使用例を見ても巨大なプロンプトにさまざまな装飾が付いている
私は次のようにとてもシンプルに使っている
本当にミニマルを求めるなら、こういうカスタマイズフレームワークは必須ではない
他のシェルやプロンプトに比べて、Starship の構成ファイルは複雑度が上がってもかなり直感的だという利点がある
すべての機能を無効化できる
<pre><code>format = """ $username\ $hostname\ $shlvl\ $directory\ $git_branch\ $git_commit\ $git_state\ $git_metrics\ $git_status\ $package\ $python\ $rust\ $env_var\ $custom\ $cmd_duration\ $jobs\ $time\ $status\ $shell\ $character"""</code></pre>私は今こんな感じのミニマル構成を使っている
Starship は結局ミニマルにも使えるが、本質的にはできるだけ多くの情報と内容を載せられるマキシマリスト向けプロンプトだ
この点を認めたほうがよいと思う
私はこれよりさらに細い矢印を使っている
<pre><code>PROMPT='%{%F{red}%}%~ %{%F{yellow}%}% › %{%F{reset_color}%}%'</code></pre>クリーンで、シンプルで、ミニマルに実装できる
カスタマイズ可能であることとマキシマリズムを混同している反応が多いのは驚き
デフォルトは少し盛りすぎだが、望むだけ減らせる
私は複数の AWS 環境やさまざまなランタイムで働いているが、プロンプトのコンテキスト情報は実際に大きな助けになる
個人的にはずっと Starship + Nushell の組み合わせを使い続けている
一度インストールすれば、もうほとんど触らなくてよいのが好き
シェルが node 20 なのか 22 なのか、rust が stable なのか nightly なのかといった情報をすぐ見たい
そういうものを追加作業なしですぐ表示してくれるので満足している
Starship とは関係ないが、zsh プロンプトで Enter を押すとカーソルが一瞬行頭に動いて「フラッシュ」する現象が不快
ultra-fast なプロンプトでは多少ましだが、プロンプトで何か少しでも動作するとこの現象が非常によく見える
複数のターミナル(gnome-terminal、wezterm、kitty、alacritty、xterm)で同じように観察される
唯一 urxvt ターミナルではこの問題が発生しない
動画による再現 参照
このフラッシュ現象の原因や回避法が知りたい
git status などの役に立たない情報を、プロンプトがレンダリングされるたびに 100ms ごとに確認させるようなことをすると、見えない生産性低下につながる
ターミナルは反応的な記憶ツールであるべきで、不要な装飾になるものは避けるべきだ
コード実行速度には気を遣うのに、自分のタイピング遅延(latency)には寛容になってしまうのが問題
Starship は本当に速い
必要なデータ収集には数 ms しかかからず、どの情報を抽出するかも簡単に制御できる
これまで使った他のツールでは、長く感じる遅延のせいでいつも不快だったが、Starship を使うと体感差がはっきり分かる
人が感じる 100ms と CPU 最適化の 100ms はまったく別物
私としては、プロンプトが git ブランチや状態表示に 100ms かかって「流れ」が切れることと、自分がコマンドを直接入力するのにもっと時間がかかることのどちらを優先して最適化すべきか考えてしまう
適度な利便機能のために数 ms 使うのは十分見合う価値がある
結局は利便性とミニマリズム、その間のバランスを取ることになる
極端なミニマリズムも過剰な装飾も、どちらも非効率につながりうる
この遅延が気になったので、kitty ターミナルをパッチして Starship プロンプトを vim や emacs のように下部の status bar(モデルライン)へ移して使っている
モデルラインは非同期で更新されるため、プロンプトの反応が非常に速い
downside は kitty を自分でパッチする必要があることと、自分の個人 Linux 環境以外ではテストできていないこと
関連パッチプロジェクト 参照
プロンプトツールが TUI のように、プロンプト出力を完全に返した後でもプロンプト領域を非同期に修正する方式(たとえば kubectl、git、aws cli があとから 200ms 後に情報を追加表示するような形)が可能なのか気になる
こうすればユーザーは待たずにすぐ次のコマンドを打てて、付加情報はあとから自然に表示できる
コード実行の最適化よりも、むしろ使うレイヤーが増えることで実際にはプロンプトの入力遅延最適化がより難しくなっている状況なのではないかと思う
公式サイトに行ったとき、なぜ Starship を使うべきなのかについての明確な説明が不足していると感じた
<pre><code>- 最後のコマンド結果(色: 緑、赤、紫)最近の私のプロンプトカスタムでは、以下の情報をひと目で見られる
最後のコマンドが成功なら緑、失敗なら赤、中断された場合は紫で表示
自分は彼らのターゲットユーザーかもしれないが、ホームページでは「なぜ」使うべきなのか、何が改善されるのかが明確に伝わってこない