Я подозреваю, что вы не настроили отслеживание восходящего потока для текущей ветви. Тогда git fetch вообще ничего не делает. Вместо этого попробуйте
git fetch origin master
(при условии, что вам нужен восходящий поток и ветвь).
Похоже, вы также не понимаете значения exec в найденном вами коде. Это заменит текущий исполняемый скрипт на обновленную версию и запустит его с самого начала. Нет никакого способа, которым
update_code
echo "some stuff"
будет echo "some stuff" сразу после обновления. Вместо этого он выполнится снова, надеюсь, на этот раз с обновленной версией кода.
Однако
[ -n $(git diff --name-only origin/$BRANCH | grep $SCRIPTNAME) ]
- действительно обходная и потенциально хрупкая конструкция. Вы спрашиваете, вернул ли grep какой-либо (непустой) вывод ... но очевидно, что grep сам по себе является инструментом для проверки наличия совпадений. Кроме того, использование SCRIPTNAME здесь хрупко - если скрипт был вызван с путем, подобным /home/you/work/script/update_self_test, это то, что содержит SCRIPTNAME, но git diff будет выводить только относительный путь (script/update_self_test в этом случае, если /home/you/work является Git рабочим каталогом), поэтому grep завершится ошибкой. (В вашей bash -x расшифровке вы видите grep /opt/script/firstScript - это именно эта ошибка.)
Поскольку вы уже находитесь в каталоге с файлом, я бы рекомендовал
git diff --name-only origin/master "$(basename "$SCRIPTNAME")"
который ничего не напечатает, если файл не изменился, и имя файла этого отдельного файла, если он изменился. К сожалению, это не устанавливает его код завершения, указывающий на успех или неудачу (я думаю, что это трудно определить здесь, хотя традиционное соглашение для обычной команды diff - сообщать ненулевой код выхода, когда есть различия), но мы можем использовать
git diff --name-only origin/master "$(basename "$SCRIPTNAME")" | grep -q . &&
для всего условного. (Обратите внимание также Когда обернуть кавычки вокруг переменной оболочки? )
Наконец, у вашей собственной попытки также есть другая проблема. Помимо сбоя exec, у вас есть неоднозначные перенаправления. Вы пытаетесь отправить материал в файл a.txt, но вы также пытаетесь отправить тот же материал на /dev/null. Что он? Решайтесь.
Для чего это стоит,
echo testing >a.txt 1>/dev/null
отправляет testing на /dev/null; сначала он перенаправляет стандартный вывод на a.txt, но затем обновляет перенаправление, так что вы просто создаете пустой файл в a.txt, если он еще не существует.
В конце концов, вам, вероятно, также следует переключиться на нижний регистр для ваших личных переменных; но я вижу, что вы просто скопировали неверное соглашение из другого ответа.