Почему использование set -e приводит к сбою моего скрипта при вызове в crontab? - PullRequest
Новая
       14

Почему использование set -e приводит к сбою моего скрипта при вызове в crontab?

2 голосов
/ 20 мая 2010

У меня есть скрипт bash, который выполняет несколько файловых операций.Когда какой-либо пользователь запускает этот скрипт, он успешно выполняется и выводит несколько строк текста, но когда я пытаюсь его обработать, возникают проблемы.Кажется, он запускается (я вижу запись в журнале cron, показывающую, что он был запущен), но ничего не происходит, он ничего не выводит и не выполняет никаких файловых операций.Он также нигде не отображается в запущенных процессах, поэтому он немедленно завершает работу.

После некоторого устранения неполадок я обнаружил, что удаление «set -e» решило проблему, теперь она запускается из системного cron без проблем.Так что это работает, но я бы предпочел включить -e, чтобы скрипт завершал работу при возникновении ошибки.Кто-нибудь знает, почему «set -e» вызывает мой скрипт для выхода?

Спасибо за помощь,
Райан

Ответы [ 2 ]

4 голосов
/ 20 мая 2010

При set -e скрипт остановится на первой команде, которая дает ненулевой статус выхода. Это не обязательно означает, что вы увидите сообщение об ошибке.

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

Без set -e: 

$ cat test.sh
#!/bin/sh

false
echo Hello

$ ./test.sh
Hello
$

Но тот же скрипт с set -e завершает работу, ничего не печатая: 

$ cat test2.sh
#!/bin/sh

set -e

false
echo Hello

$ ./test2.sh
$

Исходя из ваших наблюдений, кажется, что ваш скрипт по какой-то причине выходит из строя (предположительно связан с другой средой, как предположил Джим Льюис), прежде чем он генерирует какой-либо вывод.

Для отладки добавьте set -x в начало скрипта (а также set -e), чтобы показать команды по мере их выполнения.

4 голосов
/ 20 мая 2010

Когда ваш скрипт выполняется в cron, переменные среды и путь могут быть установлены иначе, чем когда скрипт запускается непосредственно пользователем. Может быть, поэтому он ведет себя по-другому?

Чтобы проверить это: создайте новый скрипт, который ничего не делает, кроме printenv и echo $PATH. Запустите этот скрипт вручную, сохранив вывод, а затем запустите его как задание cron, сохранив этот вывод. Сравните две среды. Я уверен, что вы найдете различия ... интерактивный В оболочке входа будет настроена среда путем выбора источников ".login", ".bash_profile", или аналогичный скрипт (в зависимости от оболочки пользователя). Это обычно не произойдет в задание cron, которое обычно является причиной того, что задание cron ведет себя не так, как запущено тот же сценарий в оболочке входа в систему.

Чтобы это исправить: в верхней части скрипта либо явно установите переменные окружения и PATH, чтобы соответствовать интерактивной среде, или источник ".bash_profile" пользователя, ".login" или другой скрипт установки, в зависимости от того, какую оболочку они используют.

...