この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
Linuxを使っていると、ある日突然すべてのコマンドが動かなくなるという恐怖の体験をすることがあります。lsも、cdも、catも──何を打っても「command not found」。画面を見ながら頭が真っ白になる、あの感覚は、一度経験した人なら忘れられないはずです。
実はこれ、かなり多くのLinux学習者・エンジニアが一度はやらかす「環境変数PATHの破壊」が原因です。設定ファイルにexportを書いた直後に起きることが多く、「私だけがやってしまったのでは」と思われがちですが、私がセミナーで3,100名以上を指導してきた中でも、同じ相談は繰り返し届きます。
この記事では、私がSE時代に実際にやらかした「.bash_profileへの誤ったexport記述でPATHを壊して全コマンドが使えなくなった経験」を正直に語りながら、なぜこうなるのか・どう回復するのかを解説します。「export PATHを書いたら突然おかしくなった」という方は、ぜひ最後まで読んでください。
この記事のポイント
・PATHに$PATHを書き忘れると既存のパスが消えすべてのコマンドが使えなくなる
・PATHが壊れても「絶対パス」（/bin/vi など）でコマンドを実行すれば回復できる
・変更前バックアップと作業中の別セッション保持が事故防止の2大鉄則
・仕組みを理解するとトラブル発生時も手が止まらなくなる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Linuxの環境変数PATHが壊れると何が起きるのか
まず、PATHとは何かを簡単におさらいします。
Linuxでコマンドを打つとき、シェルは「どこにそのコマンドの実体ファイルがあるか」を探す必要があります。たとえば
ls を実行すると、シェルは /bin/ls や /usr/bin/ls という実行ファイルを探して動かします。この「どのディレクトリを探すか」を定義しているのが、環境変数PATHです。通常、PATHは以下のような値になっています。
# 環境変数PATHの中身を確認する echo $PATH # 出力例: # /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/home/user/.local/bin
ls と入力するだけでシェルが /usr/bin/ls を見つけて実行してくれます。コロン（:）区切りで複数のディレクトリを登録しており、シェルは左から順番に探していきます。ところが、このPATHを誤った値に上書きしてしまうと、シェルはコマンドの在り処を探せなくなる。結果として、何を打っても「command not found」になってしまうのです。
「PATHに /bin や /usr/bin が含まれていないと、ls どころか vi すら動かなくなる」──これがPATH破壊の本質です。シェルは指定されたディレクトリ以外を探しに行かないので、必須コマンドの在り処が消えてしまえばお手上げになります。
SE時代にPATHを壊してパニックになった経験
1. 誤ったexportを.bash_profileに書いてしまった
あれは2003年頃の話です。勤務先の社内開発サーバー（Red Hat Linux 9）にJava（JDK 1.4）をインストールし、
java コマンドをどこからでも使えるようにするために、PATHを設定しようとしていました。上司から「PATHに追加するには、.bash_profileをexportで書き換えればいい」と言われ、その意味を深く考えずにviでファイルを開き、末尾に追記しました。
私が書いたのは次のような内容でした。
# 【NG例】$PATHを引き継がない誤った書き方 # この行を.bash_profileの末尾に追記してしまった export PATH=/usr/local/jdk1.4/bin
$PATH が抜けていたのです。正しくは export PATH=/usr/local/jdk1.4/bin:$PATH と書くべきところ、既存のパスを引き継ぐ変数展開の記述を書き忘れていました。当時の私には「:$PATHとは何か」という意識がまったくなかった。「新しいパスを書けばいい」という表面的な理解しかなく、既存パスを引き継ぐという概念すら頭になかったのです。
このファイルを保存し、
source ~/.bash_profile を実行した瞬間、画面の様子が変わりました。2. 全コマンドが使えなくなった恐怖の瞬間
次に
ls と打ったら、こう返ってきました。# lsを実行しようとしたが... ls # -bash: ls: command not found # PATHを確認してみる echo $PATH # /usr/local/jdk1.4/bin # ← /bin も /usr/bin も /usr/sbin も消えている！
echo $PATH を打つと、PATHが /usr/local/jdk1.4/bin だけになっていました。/bin も /usr/bin も /usr/sbin も消えていたのです。ls、cat、vi、which、whoami──ありとあらゆるコマンドが「command not found」。これで私は完全にパニックになりました。「サーバーが壊れた」と思い込んで、すぐに隣の席の先輩エンジニアを呼びに行きました。
先輩は画面を見て、「あ、PATH壊れてるね」と冷静に言いました。その落ち着いた声が、余計に焦りを募らせた記憶があります。「壊れてるってなんですか！直るんですか！」と半泣きで聞いた私に、先輩は「大丈夫、設定ファイル直せばいいだけ」と返してきました。
3. 先輩に言われた「絶対パスで打て」という言葉
先輩がひと目見て状況を把握し、こう言いました。「PATHが壊れてるだけだから落ち着け。絶対パスでコマンドを打てばいい」と。
そして先輩が打ち込んだのは
/bin/vi ~/.bash_profile という一文でした。コマンド名だけでは通らなくても、フルパス（絶対パス）で指定すれば実行できる──PATHは「コマンド名→実体ファイルの場所を解決する辞書」にすぎないので、最初から絶対パスで指定すれば辞書を使わずに済むのです。
この瞬間、私の中で「Linuxのコマンドとは何か」という理解が変わりました。コマンドとは実体ファイルの「短縮名」に過ぎない。そのショートカット機能がPATHによって実現されているだけで、実体さえ分かれば絶対パスで呼び出せる──この理解が、その後のLinux運用の土台になりました。
20年以上経った今でも、この体験は鮮明に覚えています。Linuxを「なんとなく使っていた」私が、初めてシェルの仕組みを腹の底から理解した瞬間でもありました。
コマンドが動かないエラーと回復手順｜PATHが壊れた時の3ステップ
実際にPATHを壊してしまった場合の回復手順を整理します。焦っていると思考が止まりやすいので、手順を頭に入れておくことが大切です。
1. 絶対パスでviを起動して.bash_profileを開く
まず、コマンド名ではなく絶対パスを使って設定ファイルを開きます。
# PATHが壊れていても絶対パス指定なら動く /bin/vi ~/.bash_profile # nanoが好みの場合はこちら /usr/bin/nano ~/.bash_profile # lessで中身を読み取り専用で確認したい場合 /usr/bin/less ~/.bash_profile
2. PATHの設定行を正しい書き方に修正する
.bash_profile 内の誤ったPATH行を確認し、正しい形式に直します。ポイントは必ず既存のPATH（
$PATH）を引き継ぐことです。# 【NG例】既存のPATHが丸ごと消える書き方 export PATH=/usr/local/jdk1.4/bin # 【OK例1】新しいパスを先頭に追加する（優先度を上げたい場合） export PATH=/usr/local/jdk1.4/bin:$PATH # 【OK例2】新しいパスを末尾に追加する（優先度は低くてよい場合） export PATH=$PATH:/usr/local/jdk1.4/bin
$PATH という変数展開の記述が「今あるPATH全体を引き継ぐ」という意味を持っています。3. sourceコマンドで設定を再読み込みして確認する
ファイルを修正したら、設定を反映させます。
# 設定ファイルを現在のシェルセッションに再読み込みする source ~/.bash_profile # または . コマンドでも同じ動作をする . ~/.bash_profile # 反映後にPATHを確認する echo $PATH # /usr/local/jdk1.4/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin # lsが正常に動くか確認 ls /home
echo $PATH を打って、修正前に存在していた /bin や /usr/bin が含まれていればOKです。その後 ls や vi が動くことを確認してください。PATHを正しく設定するための実務上の鉄則
この経験から、私はPATH設定に関していくつかの鉄則を守るようになりました。セミナーでも必ず伝えている内容です。
鉄則1：$PATHを必ず引き継ぐ
新しいパスを追加する時は、必ず既存の
$PATH を引き継ぐように書きます。export PATH=/新しいパス:$PATH（先頭追加）または export PATH=$PATH:/新しいパス（末尾追加）の形が基本です。コピペするなら、この形式を定型文として覚えてしまう方が確実です。鉄則2：source前にファイルの中身を必ず確認する
.bash_profileや.bashrcを編集したら、sourceを実行する前に必ずPATH行を目視で確認します。「保存したはず」と「実際に書いた内容」がズレることは意外に多い。特に深夜作業や急ぎの作業時は要注意です。
鉄則3：変更前にバックアップを取る
.bash_profileを編集する前に必ず
cp ~/.bash_profile ~/.bash_profile.bak でバックアップを取ります。壊れてもすぐ戻せる状態を確保してから作業する──これは設定ファイルを触る時の基本姿勢です。# 編集前にバックアップを取っておく cp ~/.bash_profile ~/.bash_profile.bak # 万が一壊れたら絶対パスで元に戻す /bin/cp ~/.bash_profile.bak ~/.bash_profile source ~/.bash_profile
設定変更中は、別のSSHセッションを切らずに残しておく習慣があります。PATHが壊れて現在のセッションでコマンドが通らなくなっても、別セッションから修正できます。ログアウトしてしまうと、次のログイン時に.bash_profileが自動的に読み込まれてPATHが壊れた状態になるため、最悪の場合ログインすらできなくなります。
私のセミナーで3,100名以上を指導してきた中で、「.bash_profileを壊してSSHログインできなくなった」という報告を複数回受けています。共通しているのは「作業中に他のセッションを閉じてしまった」というケースです。複数セッションを保持していれば、片方が壊れても残りのセッションで修正できます。
PATHの仕組みを理解するとLinux運用が変わる
PATHという仕組みは、一度理解してしまえばとてもシンプルです。しかし「なんとなく動いていた」段階では、壊れた時に何も手が出せません。
私がSE時代にやらかしたこのPATH破壊事件は、今考えると「Linuxをちゃんと理解していなかった証拠」でした。コマンドをコピペで設定し、なぜそう書くのかを考えていなかった。先輩の一言「絶対パスで打て」で、シェルがコマンドをどう解決しているかを初めて意識できた。
Linuxの仕組みを「動く理由」から理解していれば、トラブルに遭遇した時の打ち手が見えてくる。逆に「なんとなく動いている」状態では、壊れた瞬間に思考が止まります。
受講生からよく聞かれる質問が「コマンドを全部暗記しなければいけませんか？」というものですが、私の答えは「暗記より仕組みを理解する方がずっと大切」です。PATHひとつ理解しておくだけで、「なぜエラーが出るか」「どう直すか」の見当がつく。これがLinuxを学ぶ本当の価値です。
20年以上サーバーを運用してきた経験から言うと、現場で本当に頼りにされるエンジニアは「コマンドを多く知っている人」ではなく「仕組みを理解して自分で考えられる人」です。PATHが壊れても焦らず絶対パスで対処できる人と、画面を前に思考停止する人──この差は、表面的なコマンドの知識量ではなく、Linuxの仕組みの理解度から来ています。
関連記事：
・bashの設定ファイル完全解説｜/etc/profile・~/.bash_profile・~/.bashrcの違いと使い分け
・環境変数PATHの設定方法｜パスの追加・永続化・RHEL9対応の手順
まとめ
今回の記事の内容を整理します。
| 状況 | 対処・注意点 |
|---|---|
| PATHが壊れてコマンドが動かない | 絶対パスでviを起動（/bin/vi ~/.bash_profile）して修正する |
| 誤ったPATH設定の正しい修正方法 | export PATH=/追加パス:$PATH の形式で$PATHを必ず引き継ぐ |
| 設定を現在のシェルに反映させる | source ~/.bash_profile または . ~/.bash_profile |
| 変更前の事故防止策 | cp ~/.bash_profile ~/.bash_profile.bak でバックアップを取る |
| SSH作業中の鉄則 | 作業中は別のSSHセッションを必ず残しておく |
| PATH破壊の根本原因 | $PATHの引き継ぎを書き忘れた（既存パスが全て消えた） |
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
リナックスマスター.JPでは、20年以上の現場経験を持つ講師が直接指導する「Linux Master Pro Seminar」を開催しています。PATHの仕組みや.bash_profileの正しい扱い方から始まり、本番サーバーで使える「確認の型」「変更の型」「回復の型」を2日間で体得するハンズオン型セミナーです。独学では気づきにくい「現場の当たり前」を、失敗を最小化しながら習得できます。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxサーバーのタイムゾーン設定ミスで障害ログの時刻がズレていた日の話
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます