web-dev-qa-db-ja.com

/ usr / bin / env：php：そのようなファイルやディレクトリはありません

アプリのデプロイに.shスクリプトを使用したいのですが。このスクリプトは私のホームサーバー（Ubuntu 15.10サーバー）にあり、実行可能としてマークされています。このスクリプトへのアクセスは、sshを介して this チュートリアルを使用して行われます。このスクリプトを実行するsshログインを設定しました。したがって、基本的にはssh [email protected] someArgumentsを呼び出すだけで、someArgumentsをパラメーターとしてスクリプトを実行します。ユーザーdeployerにはuid = 0があるため、基本的にはroot（これは将来変更される予定です。正常に機能するまで、権限の問題を排除するためにのみ設定しました）。

そして、ここが物事がトリッキーになるところです。スクリプトは、コマンド/usr/bin/env: php: No such file or directoryで/bin/composer installを報告します（- Composer を使用）。私がそのスクリプトを見ると、状況はより奇妙になります。この行の前には、/bin/composer self-updateおよび/bin/composer -Vもあり、どちらも正しく実行され、正しい出力を表示します。

次のことを確認しました。

  • /usr/bin/env php -vは正しいPHPバージョン（/usr/bin/php -vと同じ）を表示します）
  • whereis phpはphp: /usr/bin/php /usr/local/bin/php /usr/share/man/man1/php.1.gzを表示します
  • php5-cliパッケージがインストールされ、最新バージョン
  • $PATHには/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/gamesが含まれています
  • which envは/usr/bin/envを表示します

私は以下のものも試しました：

  • rootの下でbash deploy.shとして直接スクリプトを実行します（そのユーザーと同じであるため）-エラーなしで完全に機能します
  • 失敗したコマンドを直接実行する-完全にエラーなし

だから、これは非常に特殊なケースとして私には思えます、なぜこのコマンドが機能しないのですか？デバッグに12時間費やしましたが、ここでは考えきれません。

PS：/usr/bin/env: node: No such file or directoryがあると同様のエラー（bower install）が発生します（ Bower を使用）、 ではありませんnpm installを実行する場合（- [〜＃〜] npm [〜＃〜] を使用）。

linuxubuntubashsshphp
9
Tomáš Blatný

行末および/または目に見えないスペースが問題を引き起こしていないことを確認してください。

スクリプトの最初の行のスペースを削除し、新しいスペースを挿入します。スペースを押すときにCTRLキーを押したままにしないでください。

また、DOSの行末（CR + LF）がないことを確認してください。詳細は https://stackoverflow.com/questions/82726/convert-dos-line-endings-to-linux-line-endings-in-vim を参照してください。

6
neuhaus

最も簡単な方法....ユーザーのシェルをスクリプトとして変更します。

/ etc/passwd

Before:
deploy:x:0:0:,,,:/root:/bin/bash

After:
deploy:x:0:0:,,,:/root:/scripts/deploy.sh

スクリプトの例（実行ビットがchmod + xに設定されていることを確認してください）

/scripts/deploy.sh

#!/bin/bash 
PATH=$PATH:/moo etc...
moo.sh

Sample いつでも動作します！スクリプトを使用して、設定されていないと思われる可能性のある環境変数をトラブルシューティング/デバッグすることもできます。また、sshに渡される処理引数も機能します。

注：スクリプト、実行可能ファイルなどのパスを常に完全に修飾することをお勧めします。上記は、デフォルトのパスを設定してmoo内のmoo.shを呼び出すことを許可する例ですフォルダー;）

それは簡単でした..投稿していただきありがとうございます..

リファレンス： / etc/passwd format

4
NotAdmin Dave

envコマンドは、ユーザーの$PATHを調べて、指定された名前の最初の実行可能ファイルを見つけます。したがって、/usr/bin/env phpは、それを実行しているユーザーの$PATH内の任意のディレクトリでphpという実行可能ファイルを探します。

あなたの場合、それはほぼ確実です。sshでコマンドを実行すると、完全なシェルを起動せず、実際にシェルの初期化ファイルを読み取らないためです。これを確認するには、次のコマンドを実行します（一重引用符に注意してください）。

ssh [email protected] 'echo $PATH'

そして、出力をssh [email protected]で得たものと比較し、、次にecho $PATHを実行します。私のシステムでは。例えば：

$ echo $PATH
/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/lib/jvm/default/bin:/usr/bin/site_Perl:/usr/bin/vendor_Perl:/usr/bin/core_Perl:

$ ssh localhost 'echo $PATH'
/usr/bin:/bin:/usr/sbin:/sbin

したがって、$PATHを使用して実行した場合にスクリプトがアクセスできるssh [email protected]は、ログインしてテストする場合とは異なります。

いずれの場合も、単純な解決策は、envではなく、インタープリターへのフルパスを使用することです。 envとフルパスの両方に 利点と欠点 がありますが、この場合、パスの方が安全です。

#!/usr/bin/php
4
terdon

bashのハッシュテーブルをリセットする必要がある可能性はありますか？

その場合は、スクリプトのどこかにhash -rを追加してみてください。これにより、シェルはハッシュテーブルからの（おそらく古い）情報に依存するのではなく、$PATHをもう一度調べます。

必要に応じて、hashを使用すると、シェルは-pオプションを使用して非標準の場所にインストールされた実行可能ファイルへのパスを記憶したり、-dオプションでパスを忘れたりすることができます。

出典：

https://unix.stackexchange.com/a/86017/121251
https://stackoverflow.com/a/22543353/214684

2
flyingfinger

パスにphpを追加する必要があるようです。試してください：

vim ~/.bashrc
PATH=$PATH:/usr/local/bin/php
export PATH

また、phpがどこにあるかをチェックして、パスが正しいことを確認することもできます。試してください：

which php
1
Jeramy

通常のsshログインを実行すると、デプロイスクリプトがパス上にあるものを確実に見つけられないため、パスの問題があることは明らかです。

PATHの問題があることを確認するために最初に行うことは、envまたは少なくともecho $PATHの出力をログに記録するようにデプロイスクリプトを更新することです。デプロイスクリプトの呼び出し方法、$ PATHが期待どおりに設定されていないと思います。このデバッグ出力は私の理論を確認/否定します。

あなたが従ったチュートリアルを見ました。スクリプトが正しいシェルで実行されていることを確認していない場合は、command=をcommand="/bin/sh /path/to/your/script..."に更新することを確認してください。

PATHの問題がある場合、迅速でダーティな修正は、デプロイスクリプトの最初に明示的にPATHを設定することです。

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

詳細な説明とその他のオプション...

Linuxでは、コマンドが実行されると、親プロセスの環境を継承します。

SSHを介して通常のユーザーとしてログインすると、次のようなことが起こります（/ etc/bashrc/etc/profile〜/ .bash_profile〜/ .bashrcなどの実行）。その時点で、これらのスクリプトでexport PATH="$PATH:~/mybin"などを実行して、プロセスの環境を更新している可能性があります。これで、今後実行するプロセスは現在の環境を継承します。

ログインシェルを取得する代わりにコマンドを実行すると、コマンドはsshデーモンによって実行され、sshデーモンプロセスの環境を継承します。これは、ログインユーザーとしての環境とは異なる可能性があります。

認証済みキーのmanページ は、認証後に何が起こるかをカバーしています。環境について：

  1. ファイル〜/ .ssh/environmentが存在する場合はそれを読み取り、ユーザーは環境を変更できます。 sshd_config（5）のPermitUserEnvironmentオプションを参照してください。

したがって、プロセスの環境を構成する適切な場所は~/.ssh/environmentです。ここで、~は、コマンドを実行するために認証されたユーザーのホームディレクトリです。また、sshd_configをチェックして、PermitUserEnvironmentが許可されていることを確認する必要があります。

もちろん、~/.ssh/environment形式もマニュアルページで指定されています。

         This file is read into the environment at login (if it exists).
         It can only contain empty lines, comment lines (that start with
         '#'), and assignment lines of the form name=value.  The file
         should be writable only by the user; it need not be readable by
         directory becomes accessible.  This file should be writable only
         by the user, and need not be readable by anyone else.

上記の方法を使用せずに環境を指定する別の方法は、authorized_keysファイルでenvironment="NAME=value"オプションを使用することです。詳細については、上記でリンクしたmanページを参照してください。

1
mattpr