コマンドが見つからない…　WP-CLIが動かない理由

「wp-cli.phar をダウンロードして ~/bin/wp にアップロードした。SSH でログインして叩いたのに、-bash: wp: command not found。ファイルは確かに置いたのに、なぜ？」

ConoHa WING 環境で WP-CLI を動かそうとした際、こういう症状に出くわすことがあります。実体ファイルは存在し、パーミッションも 755、サイズも 6.8 MB（正規 PHAR と一致）。けれど起動しない。実は「コマンドが見つかりません」というメッセージの裏側には、まったく別の原因が潜んでいることがあります。

ファイルはあるのに動かない

サーバーに SSH でログインして、~/bin/wp の存在を確かめてみると：

$ ls -la ~/bin/wp
-rwxr-xr-x 1 c1234567 c1234567 7142777 May  8 10:00 /home/c1234567/bin/wp

$ wp --info
-bash: wp: command not found

PATH（コマンドを名前だけで実行できるよう登録された検索場所）に ~/bin が入っていないからかと思いきや、絶対パス（フルパス）で呼んでも結果は変わりません。

$ ~/bin/wp --info
-bash: /home/c1234567/bin/wp: cannot execute binary file

cannot execute binary file（実行可能なバイナリではない）まで来ると、いよいよ「ファイルそのものに何かある」と疑いたくなります。

真因 — PHAR の `broken signature`

WP-CLI は wp-cli.phar という単一の PHAR ファイル（PHP の自己完結アーカイブ形式・WP-CLI の全コードを 1 つの実行可能ファイルにまとめた形）で配布されています。PHAR は中に SHA1 署名 を持っており、PHP がロード時に「アーカイブが書き換わっていないか」を検証する仕組みです。

wp を php 越しに直接叩いて、見えていなかった stderr（標準エラー出力）を確認すると：

$ php ~/bin/wp --info
Fatal error: Uncaught PharException: phar "/home/c1234567/bin/wp"
SHA1 signature could not be verified: broken signature in
/home/c1234567/bin/wp:3

これが真因。ファイルの中身が 1 バイトでも書き換わっていると、PHAR はロードを拒否するように設計されています。Mac でダウンロードした正規 PHAR と、サーバーに着いた PHAR の中身が一致していない、ということがエラーから読み取れます。

なぜブラウザのファイルマネージャー経由で壊れるのか

クライアントの作業手順は典型的にこういう流れでした：

Mac で WP-CLI 公式から wp-cli.phar をダウンロード
Finder でファイル名を wp にリネーム（拡張子 .phar を削除）
ConoHa の ファイルマネージャー（ブラウザベース） で ~/bin/ にドラッグ＆ドロップ

問題は ③ の段階です。ファイルマネージャー上で wp のアイコンが「txt」と表示され、属性ダイアログでも「プレインテキスト」と判定されることが確認できました。拡張子の無いファイルは MIME 判定（中身が何の種別かを推測する仕組み）に失敗してテキスト扱いになる仕様で、転送経路上で改行コードや文字エンコーディングが書き換わってしまう。

実機で同じ手順を別アカウント・別タイミングで複数回試したところ、毎回 違う MD5 ハッシュ（中身が一致するか確認するための短い文字列）の壊れ方が観測できました。決定論的な破損ではなく、何らかの変換が掛かっていることが分かります。

解決策 — Mac を経由しない

確実なのは SSH でサーバーにログインしてから、サーバー上で curl コマンドで直接ダウンロードするルートです。Mac の Finder もブラウザのファイルマネージャーも経由しないので、転送経路で書き換わる余地がありません。

ssh -i ~/.ssh/<秘密鍵.pem> -p 8022 <SSHユーザー>@<ホスト名> '
  mkdir -p ~/bin && cd ~/bin &&
  [ -f wp ] && mv wp wp.broken_backup_$(date +%s);
  curl -sO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar &&
  mv wp-cli.phar wp && chmod 755 wp &&
  ~/bin/wp --info
'

既存の壊れた wp は wp.broken_backup_<タイムスタンプ> に退避してから新規取得する、何度実行しても安全なワンライナーです。最後の wp --info で WP-CLI のバージョンが返ってくれば成功。30 秒で終わります。

教訓 — バイナリは SFTP/SSH 経由のみ

ファイルマネージャーは便利な反面、バイナリファイルを「テキスト扱いで途中変換してしまう」リスクを持っています。今回は PHAR の SHA1 署名検証という設計のおかげで「データ破損が静かに進行する」ことを防げましたが、署名検証を持たない他のバイナリ（実行ファイル・ZIP・画像のメタデータ等）なら、気付かないうちに壊れたファイルを掴まされる可能性があります。

加えて、ハッシュ照合だけで「健全」と判定するのは危険。MD5 が一致していても broken signature を起こすケースが実機で確認できているので、最終的な動作確認は必ず wp --info の終了ステータス（コマンドが成功したか失敗したかを表す番号・成功なら 0）と出力で取るべき、というのが今回の調査で得た確信でもあります。

ホスト別のアーキテクチャ事情については WP-CLI が動かない 4 ホスト実機調査もあわせてどうぞ。