この記事では、ホスティングサービスでphpスクリプトを実行する際の微妙な点について説明しますが、これを知らないと、初心者プログラマーや中流のマスターの両方にとって多くの神経が台無しになります。
この記事を書く理由：異なる設定でホスティングサービスでスクリプトを実行する際の問題。 また、設定が異なる場合があるため、一般的な場合に提供される情報は適切で誤解を招く可能性があります。
これらのリンクに関する少しの理論： こことここで 、記憶をリフレッシュしたい人のために。
ケース1
オペレーティングシステムの設定では、デフォルトのパスは指定されていません。 その結果、cronの次のコマンドは実行されません。
php /var/www/LOGIN/data/www/SITE/cron.php
正しいコマンドが2番目のオプションになり、PHPインタープリターへのフルパスを記述します。
/usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php
ここで説明するphpスクリプトを実行する方法は他にもいくつかあります 。 ここで興味深いのは、phpスクリプトがコンソール用のコマンドを含むファイルとして起動されることです。ここでは、すべてのコマンドを記述し、あらゆる好みのあらゆる種類のオプションを記述できます。 コードは次のようになります。
#!/usr/bin/php <?php ?>
cronで実行するコマンドは、スクリプトへのパスを登録しますが、それ以上は登録しません。 ＃＃記号がスクリプトに挿入され、必要なコマンドをbash言語で記述するだけです。
ケース2
ブラウザからの要求に応じてスクリプトを実行すると、ページがブラウザに出力されます。 また、cronを介してスクリプトを実行すると、ページテキストがコマンドラインに出力されます。 いくつかのオプションがあります。 システムは、出力をファイルとしてコンソールに保存するように構成できます。 さらに、このファイルは最も一般的な場所にない場合があります。 徐々に、これはすべてのディスク領域を詰まらせる可能性があります。 多くの場合、サイトには1ギガバイト、500メガバイトの場所が与えられます。 また、サイトごとに50メガバイトと10メガバイトのホスティングもありました。
または、出力をメールボックスにリダイレクトすることもできます。メールボックスは、思いやりのあるホスティング業者が控えめに提示し、デフォルトでホスティング設定にメールとして登録します。 スクリプトが実行されるたびに、コンソールに表示されるすべてのテキストが文字で実行されます。 問題が予期せず開始する場合があります。 cronタスクが頻繁に実行され、ホスティングメールで1日あたりの文字数に制限がある場合、メールは単純に分類されます（プロバイダーによって潜在的なスパマーとしてブロックされます）。 そして、不快な結果として、メールに関連付けられているユーザーの登録拒否、ユーザーの通知などを受け取ります。
決定は世界と同じくらい古いです。 コンソールからの出力をvoidにリダイレクトする必要があります。 これを行うには、kronaコマンドの最後にコマンドを追加します。
>/dev/null 2>&1
ホスティング管理者が、ユーザーとして目立たないようにする責任を負う場合があります。 落とし穴もあります。
ケース3
状況は単純です。 スケジューラーによって実行されるスクリプトをデバッグする必要があります。 PHPツールを使用してこれを実行したり、ログにログを書き込むように強制することができます。 しかし、はるかに簡単な方法があります。出力をファイルにリダイレクトする必要があります。 コマンドはシンプルで、チームの追加パラメーターです。
> /var/www/LOGIN/data/www/SITE/log.html
コマンドの最後に追加する必要があります。
/usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html
「>」記号は、システムに出力をリダイレクトするように指示します。 次はファイル名です。 この例では、絶対パスが示されています。 この例は、インターネットで見つけるのは難しくありません。 しかし、ここでは、2番目のケースから生じるトラブルが予想されます。 思いやりのあるホスティング業者が、行末に出力リダイレクトを自動的に追加します。 そして時々それを偽装します。 結果は次の形式のコマンドです。
/usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html >/dev/null 2>&1
その結果、出力は再びvoidにリダイレクトされ、出力ファイルは空になります。 ここで、ホスティング事業者は、自分の設定で自分が裏をかかれすぎたという彼の間違いを示すことができます。 そして、すぐに松葉杖を使用できます。 ファイルへのリダイレクトコマンドの後、コマンドを&&で終了します。 これら2つの文字は、同じ行で複数のコマンドを結合するためにコマンドラインで使用されます。 これらは、コマンドが終了し、次のコマンドが実行されることをコマンドラインに理解させます。 ボイドへのリダイレクトがそれに適用されます。 その結果、voidへのリダイレクトが残り、ログファイルが正しく記録されます。 コマンド例：
/usr/bin/php /var/www/LOGIN/data/www/SITE/cron.php > /var/www/LOGIN/data/www/SITE/log.html && >/dev/null 2>&1
ケース4
スクリプトは開始されましたが、正しく機能しません。 これは、コマンドラインから起動した場合、PHPインタープリターが、HTTPサーバーを介して起動した場合とは異なる、誤って構成された環境で動作を開始するためです。 最初の兆候-スクリプトは同じディレクトリ内にあるファイルを見つけませんが、サイトのルートよりも上位のいくつかのフォルダーであるユーザーのルートディレクトリにあると見なし始めます。 最初に確認するのは、環境変数と$ _SERVERスーパーグローバル配列です。
この問題についてインターネットで最初に見つけることは、ディレクトリ変更コマンドをクローネに登録することです。
cd /var/www/LOGIN/data/www/SITE/
しかし、場合によってはこれは役に立ちません。 抜け道があります。 それらの1つは、すべてを自分の手に渡して、スクリプトが機能するように不足している環境を設定します。 これについては、インターネット上ですでに多くの情報があります。
スクリプトの最初に次のコードを入力するだけで十分な場合があり、パスが再び機能するようになります。
$path_parts = pathinfo($_SERVER['SCRIPT_FILENAME']); // chdir($path_parts['dirname']); //
ご覧のとおり、すべてが関数に登録されており、設定を気にする必要はありません。
おわりに
それだけです 問題と解決策は些細なことではなく、一般的にこのような失敗した設定の組み合わせはまれです。 プロジェクトの展開と移動の際に幸運を祈ります。