0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

普段使いのシェルはbashよりzshの方が快適だった

0
Posted at

はじめに

この記事では、普段のターミナル操作では bash より zsh の方が快適だと感じた理由を整理します。

bash は標準的で、どこでも使いやすいです。
一方で、毎日ターミナルを触るなら zsh の方が操作の細かいストレスが少ないです。

特に差が出るのは、次のような場面です。

  • 長いコマンドを途中まで打って補完したい
  • 前に打ったコマンドを探したい
  • 深いパスへ移動したい
  • Git ブランチや状態を見ながら作業したい

結論だけ先に言うと、自分用の対話シェルは zsh、配布用や CI のシェルスクリプトは bash で分けるのが一番実用的でした。

先に結論

zsh が良かったと感じた理由は、派手な機能よりも日常操作の速さです。

  • 補完が強い
  • 履歴を探しやすい
  • パス移動が楽
  • プロンプトを整えやすい
  • 普段の入力ミスを減らしやすい

逆に、スクリプトを書くときは bash の方が無難です。
相手の環境に zsh が入っているとは限らないからです。

zsh は入れただけで全部便利になるわけではない

ただし、zsh の便利さは zsh 本体だけでなく、補完設定やプラグイン込みで感じる部分もあります。

何も設定していない zsh に変えただけで、すべてが劇的に便利になるわけではありません。

この記事でいう「zsh が快適」というのは、補完、履歴検索、プロンプトをある程度整えた状態を前提にしています。

この前提を分けておくと、zsh 本体の良さと、周辺ツールで得られる便利さを混同しにくくなります。

zsh が良かったのは補完がかなり楽だから

一番差を感じやすいのは補完です。

例えば Git コマンドでも、途中まで打って Tab を押したときの候補が見やすく、絞り込みもしやすいです。

git ch<Tab>

この段階で checkoutcherry-pick の候補を出しやすくなります。

bash でも補完はあります。
ただ、zsh の方が「途中まで打って候補を見る」という流れが自然です。

毎日 git docker kubectl npm のような長めのコマンドを打つなら、この差は地味に効きます。

深いパスへの移動が楽だった

zsh はパス補完もかなり使いやすいです。

例えば次のようなディレクトリがあるとします。

~/projects/my-awesome-app

このとき、zsh では省略気味でも補完しやすいです。

cd ~/p/m<Tab>

もちろん環境設定にもよります。
ただ、日常的に深いディレクトリを行き来するなら、この種の補完の気持ちよさはかなり大きいです。

WSL や Linux で開発ディレクトリを頻繁に移動するなら、ここは zsh の価値が出やすいところです。

履歴検索が bash より使いやすかった

履歴の使いやすさも大きいです。

単に history で一覧を見るより、少し打ってから過去のコマンドを探せる方が普段使いでは便利です。

例えば git と打ってから履歴を遡ると、過去の git コマンドを探しやすくできます。

git

この後に履歴を絞って辿れるようにすると、以前打った長いコマンドをかなり再利用しやすくなります。

毎回コマンドを最初から打ち直すより、過去の入力を探して少し直す方が速いです。
zsh はこの流れにかなり向いています。

プロンプトを整えると作業しやすかった

zsh はプロンプトも整えやすいです。

例えば次のように、カレントディレクトリや Git ブランチを見やすくできます。

~/qiita git:(main) %

この情報が見えていると、今どのブランチにいるか、どこで作業しているかを毎回確認しやすくなります。

特に Git 作業が多いなら、プロンプトの見やすさは想像以上に効きます。

Oh My ZshPowerlevel10k のような定番があるのも大きいです。
細かい設定を一から書かなくても、普段使いしやすい見た目に寄せやすいです。

最初は最小構成でよい

zsh を使い始めるなら、最初から盛りすぎなくてもよいです。

自分なら、まずは次のくらいで十分です。

  • Oh My Zsh
  • Git ブランチが見えるテーマ
  • zsh-autosuggestions
  • zsh-syntax-highlighting

最初から凝った設定にしすぎると、何が効いているのか分かりづらくなります。

まずは補完、履歴、プロンプトだけ整えるくらいで十分です。

細かい入力ミスに強いのも良かった

zsh は、設定次第で細かい入力ミスに気づきやすくできます。

例えばパスのタイプミスです。

cd /usr/loacl

このようなミスに対して、補正候補を出せる設定があります。

毎回これに頼るべきではありません。
ただ、日常の対話操作では「少し打ち間違えても戻しやすい」だけで気分がかなり違います。

bash から zsh に変えるときの注意点

bash で使っていた設定を、そのまま zsh に持ってくると動かないことがあります。

例えば bash では ~/.bashrc を使いますが、zsh では主に ~/.zshrc を使います。

そのため、bash で設定していた alias や PATH は、必要なものだけ ~/.zshrc に移すのがよいです。

alias ll='ls -la'
export PATH="$HOME/bin:$PATH"

全部を一気に移すより、普段使っているものから少しずつ移す方が安全です。

では bash が不要かというとそうではない

ここは分けて考えた方がよいです。

bash は今でもかなり重要です。
理由は単純で、標準性が高いからです。

特に次の用途では bash の方が無難です。

  • 配布するシェルスクリプト
  • CI で動かすスクリプト
  • サーバーでそのまま実行する運用スクリプト
  • 他の人の環境でも動かしたいスクリプト

例えば shebang も、次の形の方が通しやすい場面が多いです。

#!/usr/bin/env bash

zsh 専用の書き方に寄せると、環境依存が強くなります。

対話シェルとして zsh を使っていても、スクリプトまで zsh で書く必要はありません。

むしろ、仕事や CI で使うスクリプトは bash の方が無難です。
理由は、読む人や実行する環境が zsh を前提にしていないことが多いからです。

自分の入力を楽にするのが zsh。
他人や CI で安定して動かすのが bash。

このように分けると、zsh と bash のどちらを使うべきかで迷いにくくなります。

使い分けはこれで十分だった

実際の感覚としては、次の分け方でほぼ困りません。

  • 普段のターミナル操作は zsh
  • スクリプトや自動化は bash

普段のターミナル操作というのは、例えば次のようなものです。

cd
ls
git
docker
kubectl
npm
grep

この種の操作は、補完、履歴、プロンプトの差がそのまま快適さに出ます。
逆に、スクリプトは快適さより移植性の方が大事です。

まとめ

zsh を使ってみて良かったのは、コマンドが増えたからではありません。
普段の入力と移動が楽になったからです。

ポイントをまとめると次のとおりです。

  1. zsh は補完が強く、長いコマンドを打ちやすい
  2. 履歴検索が使いやすく、過去のコマンドを再利用しやすい
  3. パス補完やプロンプト整備が普段使いに効く
  4. ただしスクリプト用途では bash の方が無難
  5. そのため、対話操作は zsh、スクリプトは bash が実用的だった

ターミナルを毎日使うなら、zsh は見た目の好みではなく、作業効率の差として効いてきます。

コマンドライン操作そのものを速くしたい場合は、別記事「Bashのコマンドライン操作を、便利なショートカットだけ整理する]」も関連します。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?