Для примера ввода:
$ cat /tmp/foo
public $access = '1';
public $debug = '0';
public $debug_lang = '0';
public $dbtype = 'mysqli';
public $host = 'localhost';
public $user = 'template-user';
public $password = 'template-pass';
public $db = 'template_druha';
public $dbprefix = 'dsf1i_';
public $live_site = '';
public $secret = '2w9gHzPb4HfAs2Y9';
public $gzip = '0';
public $error_reporting = 'default';
Вы можете сделать:
user="$(grep '$user' /tmp/foo | sed -e 's/ *$//g' -e 's/;$//' | awk -F= '{ print $2}')"
pass="$(grep '$password' /tmp/foo | sed -e 's/ *$//g' -e 's/;$//' | awk -F= '{ print $2}')"
var = $ (...)
оценивает все это, берет его на выходе и сохраняет в переменной Распространенная ошибка при написании скриптов, которые позже будут выполняться с помощью cron, состоит в том, что вы предполагаете, что скрипт будет иметь точно такую же среду, в которой вы находитесь, когда вы входите в систему и разрабатываете его. Это не так!
Напишите скрипт4, содержащий следующую строку
OFILE=/tmp/crons.environment
(/usr/bin/whoami
/usr/bin/env ) > $OFILE 2>&1
И пусть cron запустит это
Теперь сравните вывод в /tmp/crons.environment с тем, что вы получите, когда просто введитеenv
Ваш сценарий предполагает, например, что $PATH настроен правильно для поиска всех программ, которые вы выполняете, вы также запрашиваете базу данных, могут быть дополнительные переменные среды, необходимые для правильного выполнения этих команд.
Чтобы проверить вывод задания cron. Временно измените команду, запускаемую cron, и перенаправьте stdout и stderr в известный файл, как я сделал выше.
0 * * * * /etc/scripts/script3 > /tmp/s3.out 2>&1