Поэтому у меня есть php-скрипт, который я выполняю, используя следующую команду:
php -f my_script.php myArguments Скрипт находится под управлением версии с помощью svn. Я просто обновил его, вставил команду, чтобы запустить ее в терминал, и выполнил ее. Однако выхода нет. Не сообщение об ошибке, а не печать ничего, ничего. Похоже, он никогда не начинается. Вид вроде следующего:
me:/srv/scripts# php -f my_script.php myArguments me:/srv/scripts#
Другие скрипты будут работать отлично.
Мне трудно придумать SSCCE, так как я не могу действительно поделиться кодом, который вызывает это, и я не смог воспроизвести это поведение намеренно. Я, однако, видел это дважды сейчас. Если я сохраню свои изменения, верните файл и вставьте их обратно, есть большая вероятность, что он будет работать нормально.
Тем не менее, меня беспокоит не зная, что вызывает это странное поведение. Есть ли пробельный символ или что-то, что говорит PHP не запускать или ничего выводить?
Вот что я пробовал, увидев это поведение:
Изменение скрипта, так что это просто echo 'hello'
Ввод бессмыслицы в начале скрипта, поэтому он не поддается изучению.
Вставка кода из рабочего скрипта
Раздражение головы на стене
Попытка его в другом соединении ssh терминала / шпатлевки.
Вот где это становится интересным: он действительно работает в другом терминале. Он делает все, как ожидалось.
Так есть ли у кого-нибудь какие-либо идеи, что может быть причиной этого, или вещи, которые я должен попробовать, чтобы определить проблему?
РЕДАКТИРОВАТЬ:
«Разный терминал» все еще является терминальным приложением, просто новым.
У меня есть достаточные разрешения для выполнения файла, но даже если я этого не сделал, он должен выплюнуть сообщение о том, что я этого не делаю.
Я намеренно ввел синтаксические ошибки в надежде, что я получу PHP, чтобы выплюнуть ошибку синтаксического анализа. По-прежнему не было выхода.
display_errors может быть отключен до выполнения. Вы можете включить его вручную с помощью ключа -d :
php -d display_errors=1 -f my_script.php myArguments
Я столкнулся с одной и той же проблемой, и никакое принуждение PHP к display_errors или проверка синтаксиса с помощью -l помогли
Я, наконец, решил нашу проблему, и, возможно, вы сможете найти помощь в этом решении
Проверьте свой скрипт, не используя php.ini:
php -n test_script.php
Это поможет вам отточить реальную причину – конфигурацию PHP, чужой скрипт или ваш скрипт
В моем случае это была проблема с чужим скриптом, который добавлялся через директиву auto_prepend_file в php.ini. (Или, более конкретно, несколько файлов и функций позже, когда я просверлил весь код, добавляя отладку, когда я пошел – на стороне заметки, вы можете обнаружить, что использование fwrite(STDOUT, "debug text\n"); неоценимый при попытке отладки этот тип проблемы)
Кто-то добавил функцию, которая запускалась через файл preend, но использовала символ @ для подавления ошибок для определенного вызова функции. (У вас может быть аналогичная проблема, но не связанная конкретно с php.ini, если у вас есть какие-либо дополнения в вашем тестовом скрипте, приводящие другой код)
Функция была неудачной и вызвала молчаливую смерть PHP, ничего общего с моим тестовым скриптом
Вы найдете всевозможные предупреждения о том, как использование символа @ вызывает точные проблемы, которые у меня были, и, возможно, у вас есть, http://php.net/manual/en/language.operators.errorcontrol.php .
Воспроизведение подобных симптомов:
Возьмите полностью функциональную среду PHP и @xxx_not_a_real_function_name_xxx(); свой вывод CLI, добавив эту вершину вашего скрипта @xxx_not_a_real_function_name_xxx();
Таким образом, у вас может возникнуть проблема с php.ini, или вы (или кто-то еще), возможно, использовали @ не понимая серьезных (и разочаровывающих и трудоемких) последствий, которые он вызывает при отладке