Как остановить git от записи не ошибок в stderr
У меня есть скрипт, который я использую для автоматической синхронизации различных удаленных репозиториев git. Одна вещь, которую я пытаюсь сделать со своими сценариями, — это захватить вывод stderr из каждой команды и записать все эти ошибки в текстовый файл, который затем отправляется мне по электронной почте после завершения сценария. Это предупредит меня о любых проблемах, которые мне нужно исправить.
Однако у меня возникла проблема со следующими двумя строками:
{
git fetch --prune-tags github-fetch master
git push github master
} 2> '/tmp/stderr-contents-sync_git_repositories.txt'
Проблема в том, что строка git fetch пишет в stderr следующее:
From https://github.com/XJDHDR/xjdhdr-random-code.wiki
* branch master -> FETCH_HEAD
13af304..333d602 master -> github/master
И строка git pull пишет это:
To ssh://github.com/XJDHDR/xjdhdr-random-code.wiki.git
333d602..da65970 master -> master
Моя проблема в том, что ни одна из них не является ошибкой, и они отправляются по электронной почте каждый раз, когда я запускаю скрипт. Я хотел бы знать, можно ли либо запретить git записывать эти не-ошибки в stderr, либо отфильтровывать такие сообщения из вывода stderr, сохраняя при этом подлинные ошибки.
Опция --quiet скрывает вывод, о котором я упоминал. Меня беспокоит, не скроет ли этот вариант любые возникающие ошибки? Или ошибки все же отправляются?
@XJDHDR Смотрите мой ответ: Git использует stderr не только для ошибок, но и для информативного сообщения. Подход, который я предлагаю, должен позволить вам зафиксировать неудачное выполнение команды (с их stdout/stderr) вместо того, чтобы полагаться исключительно на stderr anlone.
Документы для выборки и отправки говорят, что упомянутая опция -q @wjandrea отключает весь вывод, кроме фактических ошибок для каждого - в частности, он отключает отчеты о ходе выполнения в stderr.
Ответы 1
write all those errors into a text file
Это нет всегда ошибка, учитывая, что большинство команд Git выводят информационное сообщение на stderr, как Я упомянул здесь:
stderr as it is just informative messages, not to be consumed by machines.
Если лучше проверить статус выхода команды и отправить по электронной почте обоим стандартный вывод и стандартный вывод, если указанный статус выхода отличается от 0
Кроме того, вы выполняете два перенаправления: >, за которым следует >: второе будет воссоздать/tmp/stderr-contents-sync_git_repositories.txt: это второе перенаправление должно быть >>, а не >.
Так:
git fetch --prune-tags github-fetch master > tmp 2>&1 || cat tmp > '/tmp/stderr-contents-sync_git_repositories.txt'
git push github master > tmp 2>&1 || cat tmp >> '/tmp/stderr-contents-sync_git_repositories.txt'
Здесь я переопределяю файл tmp для каждой команды (с их stdout/stderr), и если эта команда дает сбой, я записываю или добавляю к /tmp/stderr-contents-sync_git_repositories.txt.
Это проще, чем ваше редактирование, когда вы перенаправляете команды обе в файл, даже если одна из них могла не сработать.
Вот почему я делаю cmd1 || cat >> file: часть >> запускается только в случае сбоя cmd1.
Мое редактирование должно было более точно отразить, как выглядит мой реальный сценарий. Фактический сценарий содержит около 35 строк кода внутри этих фигурных скобок, и мне нужно зафиксировать вывод stderr для всех из них. Менее утомительно просто заключить их все в фигурные скобки и иметь одно перенаправление, чем добавлять перенаправление для каждой команды. Вот что также рекомендует ShellCheck: stackoverflow.com/a/30194723/6627890
@XJDHDR менее утомительный, но менее точный: вам нужно проверить статус выхода каждой команды, как я объяснил ответ: stderr не является надежным индикатором проблем здесь.
Я перейду этот мост, когда доберусь до него. В противном случае спасибо за ответ.
Просто примечание, чтобы сделать это с каждой командой git (как в ответе), а не в конце фигурных скобок, показанных в вопросе. Если одна команда в фигурных скобках завершается ошибкой, вывод из фигурных скобок все равно может быть успешным.
Может быть, вы ищете вариант
-q/--quiet? Я не уверен, скрывает ли он такой вывод.