Cron, который выдает: bad interpreter: No such file or directory
Если вы хотите застраховаться от ошибок, это к шаманам. Я же предлагаю вашему вниманию очередную распространённую ошибку: bad interpreter: No such file or directory, – которая может возникнуть при работе с Cron. Особенно она актуально, если вы программируете не на UNIX-подобных операционных системах. Впрочем, полной ясности в данном вопросе найти сложно, но я постараюсь.
Решая свою проблему, и собирая смежную информацию по интересующему меня вопросу, я уже опубликовал результат своих изысканий в статье:
Безусловно, материал ещё нуждается в доведении до ума, но с основной задачей он вполне справляется. Прочитав статью, вы получите представление о том, что такое Cron и как им пользоваться. В данной статье я продолжу затронутую тему и предложу ряд причин и вариантов решения одной из распространённых проблем при работе с Cron, ошибка: bad interpreter: No such file or directory.
Где найти инструкцию по настройка Cron на хостинге?
Начну с того, что у каждого из хостинг провайдеров есть свои заморочки с настройками Cron. Причем способы настройки, как и сами настройки, могут со временем меняться, что следует учесть в первую очередь.
Так что если у вас возникла задача настроить Cron или появились какие-то проблемы: обратитесь в службу поддержки или поищите свежую инструкцию хостинг-провайдера по интересующему вас вопросу.
Например, я использую хостинг SpaceWeb, и первым моим действием было: поиск на сайте sweb.ru информацию о настройке Cron. Для этого в форме поиска того же Google я набрал следующий поисковый запрос: cron site:sweb.ru– и нажал кнопку Enter. Нужная мне информация была найдена на странице: help.sweb.ru/print/3880/.
Настройка Cron для запуска PHP-скрипта на SpaceWeb
Действуя в соответствии с приведёнными инструкциями, мне пришлось несколько видоизменить настройки Cron и сам php-скрипт. Попытка оставить (даже частично) ранее действующий вариант не дала желаемого результата. Что было сделано?
Изменение PHP-срикпта
Для начала в php-скрипте была удалена первая строка с хэшбангом, у меня это:
#!/usr/local/bin/php
Путь к интерпретатору теперь надо было указывать в команде (задании) Cron, что я сделал через ПУ, но об этом чуть позже.
Для указания абсолютного пути к файлам, которые я подключаю в php-скрипте, стал использовать функцию chdir(), об этом читайте в ранее упомянутой статье.
Отдельно хочу отметить и ряд нюансов связанных с символом конца строки и BOM, но этому я посвятил отдельный раздел данное статьи в её конце.
Настройка Cron через ПУ SpaceWeb
Далее, перейдя в панель управления своим хостинг-аккаунтом, я изменил команду (задание) Cron, указав, в соответствии с инструкцией, абсолютные пути к интерпретатору и скрипту, например:
`/usr/bin/which php` /home/l/login/public_html/script.php
Обращаю ваше внимание на кавычки (`...`), в которые помещен путь к интерпретатору, это те, что у клавиши с буквой ё. Как я понял, здесь используется команда авто-определения абсолютного пути к интерпретатору PHP.
Далее идёт абсолютный путь к самому php-скрипту. Он начинается с домашней папки сервера: /home. Затем указывается первая буква логина аккаунта: /l. А потом и сам логин аккаунта: /login. Например, если у вас логин spacewebто путь до корневой папки аккаунта будет иметь вид:
/home/s/spaceweb
Для простоты понимания, уточню, что корневая папка аккаунта – это та папка, в которую вы попадаете при подключении по тому же FTP. Например, для этого я использую бесплатный FTP-клиент FileZilla, и вот как выглядит корневая папка моего хостинг-аккаунта:
корневая папка аккаунта в FTP-клиенте FileZilla
Далее следует путь к php-скрипту от корневой папки аккаунта. В приведённом примере это:
public_html/script.php
Примечательно, что на SpaceWeb такой путь имеет основной сайт, другие сайты находятся в подпапках, например: sitename/public_html/script.php– учтите и этот момент.
По сути, правильно прописанные пути к интерпретатору и php-скрипту – являются решением проблемы с ошибкой: bad interpreter: No such file or directory.
Дополнительные нюансы и проблемы
Впрочем, есть и ряд дополнительных нюансов, о которых вы должны знать, чтобы решить возможные проблемы. О двух, из наиболее распространённых нюансов, я расскажу в этой части статьи.
Символ конца строки
Одна из фишек современных операционных систем заключается в том, что они используют разные варианты символа конца строки (перевод строки или разрыв строки). Например, в Windows это \r\n, в Unix – \n, в Mac OS – \r, а может и ещё как-то иначе, я нашел такой вот вариант, но это не принципиально. Главное, что при написании того же php-скрипта, на том же Windows, и его переносе на Unix платформу, могут возникнуть проблемы.
Как решить проблему с символом конца строки? Для этого я использовал бесплатный редактор Notepad++. В нём есть готовая функция: Правка > Формат Конца Строки – с вариантами преобразования в Windows, Unix или Mac форматы. Проблема решена.
преобразование формата символа конца строки в бесплатном редакторе notepad plus plus
Символ BOM
Ещё одна очень распространённая проблема. О ней я уже писал и достаточно подробно, не вижу смысла повторяться, читайте здесь:
- PHP: как удалить BOM в WordPress
Если коротко и по сути, то вам снова может помочь Notepad++. В этот раз используйте пункт меню: Кодировки – где помимо кодировок отображения, можно выбрать и нужное преобразования в UTF-8 без BOM.
преобразование кодировки файла в Notepad++ и удаление BOM
Итоги решения проблемы
В первую очередь вам нужно найти инструкция по настройке Cron вашего хостинг-провайдера или обратиться за таковой в службу поддержки. Даже если ранее всё работало нормально или проблема в чём-то другом, приведите положение дел в соответствии с инструкцией. Убедитесь, что нет проблем с символом переноса строки и BOM.
В целом, основная причиной появления ошибки: bad interpreter: No such file or directory – состоит в неправильно указанных абсолютных путях к интерпретатору и/или скрипту, но возможны и варианты. На этом у меня всё. Спасибо за внимание. Удачи!