PHP cli script ничего не выводит

Итак, у меня есть php script, который я выполняю, используя следующую команду:

php -f my_script.php myArguments

script находится под управлением версии с помощью svn. Я просто обновил его, вставил команду, чтобы запустить ее в терминал, и выполнил ее. Однако выхода нет. Не сообщение об ошибке, а не печать ничего, ничего. Похоже, он никогда не начинается. Вид вроде следующего:

me:/srv/scripts# php -f my_script.php myArguments
me:/srv/scripts#

Другие скрипты будут работать отлично.

Мне сложно придумать SSCCE, так как я не могу поделиться кодом, который вызывает это, и я не смог воспроизвести это поведение намеренно. Я, однако, видел это дважды сейчас. Если я сохраню свои изменения, верните файл и вставьте их обратно, есть вероятность, что он будет работать нормально.

Однако меня беспокоит не зная, что вызывает это странное поведение. Есть ли пробельный символ или что-то, что говорит PHP не запускать или ничего выводить?

Вот что я пробовал, увидев это поведение:

  • Модификация script, поэтому это простой echo 'hello'

  • Ввод бессмыслицы в начале script, поэтому он не поддается анализу.

  • Вставка кода из рабочего script

  • В отчаянии ударяя головой о стену

  • Попробуйте его в другом соединении ssh терминала /putty.

Здесь, где он становится интересным: он фактически работает в другом терминале. Он делает все, как ожидалось.

У кого-нибудь есть идеи, что может быть причиной этого, или вещи, которые я должен попробовать, чтобы определить проблему?

EDIT:

"Другой терминал" все еще является терминальным приложением, просто новым.

У меня есть достаточные права для выполнения файла, но даже если я этого не сделал, он должен выплюнуть сообщение, которое я не знаю.

Я намеренно ввел синтаксические ошибки в надежде, что я получу PHP, чтобы выплюнуть ошибку синтаксического анализа. Не было выхода.

ОТВЕТЫ

Ответ 1

display_errors может быть отключен до выполнения. Вы можете включить его вручную с помощью - d:

php -d display_errors=1 -f my_script.php myArguments

Ответ 2

Я столкнулся с той же проблемой, и никакое принуждение PHP к display_errors или проверка синтаксиса с помощью -l помогли

Я, наконец, решил нашу проблему, и, возможно, вы можете найти некоторую помощь в этом решении

Проверьте свой script, не используя php.ini:

php -n test_script.php

Это поможет вам разобраться в реальной причине - настройка PHP, кто-то еще script или ваш script

В моем случае это была проблема с кем-то еще script, который добавлялся через директиву auto_prepend_file в php.ini. (Или, более конкретно, несколько файлов и функций позже, когда я просверлил весь код, добавляя отладку, когда я пошел - на стороне заметки, вы можете обнаружить, что использование fwrite(STDOUT, "debug text\n"); неоценимо при попытке отладки этого типа проблемы)

Кто-то добавил функцию, которая запускалась через файл preend, но использовала символ @ для подавления ошибок в определенном вызове функции. (У вас может быть аналогичная проблема, но не связанная конкретно с php.ini, если у вас есть какие-либо дополнения в вашем тесте script, приносящий другой код)

Функция была неудачной и вызвала молчащую смерть PHP, ничего общего с моим тестом script

Вы найдете всевозможные предупреждения о том, как использование символа @ вызывает точную проблему, которую я имел, и, возможно, у вас есть http://php.net/manual/en/language.operators.errorcontrol.php.

Воспроизведение подобных симптомов:

Возьмите полностью функциональную среду PHP и сломайте свой вывод CLI, добавив в нее верхнюю часть вашего script @xxx_not_a_real_function_name_xxx();

Таким образом, у вас может возникнуть проблема с php.ini, или вы (или кто-то еще), возможно, использовали @, не понимая серьезных (и разочаровывающих и трудоемких) последствий, которые он вызывает при отладке