отправка вывода в / dev / stderr vs.> & 2

В сценариях ошибки обычно отправляются в дескриптор файла 2 с помощью &2 , то есть:

 echo "error" >&2 

Иногда вместо этого используется /dev/stderr :

 echo "error" > /dev/stderr 

Глядя на /dev/stderr , я вижу, что это только символическая ссылка на /proc/self/fd/2 , которая, в свою очередь, символическая ссылка на /dev/pts/5 (на моем текущем терминале).

Кажется немного сложнее. Есть ли какая-то логика?

Использует /dev/stderr и &2 эквивалент?

Кто-нибудь из них предпочитает другого?

3 Solutions collect form web for “отправка вывода в / dev / stderr vs.> & 2”

Специальное устройство /dev/stderr является системным, а дескриптор файла 2 (а не специальное устройство /proc/self/fd/2 ) является портативным. Если вы хотите написать непереносимый код, эти специальные устройства – это хорошее место для начала.

Есть несколько систем с /dev/stderr : Linux, конечно, и OSX . Но OSX не имеет файловой системы /proc , а ее /dev/stderr – это ссылка на /dev/fd/2 .

Дальнейшее чтение:

  • Переносимость «> / dev / stdout»
  • Какой метод следует использовать для записи сообщений об ошибках в 'stderr' с использованием 'printf' в сценарии bash?
  • патчи / awk-dev-stderr (autoconf-patches)
  • Перенаправить stderr и stdout в сценарий Bash
  • Глава 20. Перенаправление ввода-вывода (расширенный Bash-Scripting Guide)

Вы думаете о 2> , а не >2 . Или, возможно, вы думаете о >&2 . Пример, который вы даете, echo error >2 , просто создаст обычный файл с именем 2 с строкой error\n .

В bash и других оболочках путь перенаправления к стандартной ошибке заключается в использовании >&2 . Bash открывает /dev/stderr в качестве дескриптора файла 2 . Файловые дескрипторы ссылаются на &N где N – номер дескриптора. Таким образом, echo error >&2 выведет error в стандартную ошибку, в /dev/stderr .

Он также откроет /dev/stdout качестве дескриптора файла 1 . Это означает, что вы можете выполнить echo output >&1 . Однако, так как все по умолчанию печатается на стандартный вывод, это то же самое, что и сам echo output .

Теперь 2> отличается. Здесь вы перенаправляете вывод ошибки команды где-то еще. Итак, 2>file означает «перенаправить все, что напечатано в дескриптор файла 2 (стандартная ошибка) в file ».

Вы правы, >&2 более прямой и совершенно «идиоматический». Они должны быть эквивалентными, поэтому нет особых причин для использования >/dev/stderr . Кроме того, если кто-то читает, не знает, что они делают, один из них, вероятно, легче узнать, чем другой :-). Но в целом я предлагаю вам использовать >&2 .

/ dev / stderr может быть полезно, когда программы будут писать ошибки в указанное имя файла, но не поддерживают stderr. Ясно, что это немного надуманно; / dev / stdout гораздо полезнее. (Недавно я обнаружил, что mysql_safe оболочки mysql_safe не будет записывать ошибки на консоль, к сожалению, он также хочет изменить разрешения на файл журнала ошибок, поэтому использование / dev / stderr вызывает несколько лишних предупреждений).

  • Как я могу вывести stdout и stderr и записать их в файл?
  • Имеются ли отчеты о ходе выполнения / данные регистрации на stderr или stdout?
  • stderr над ssh -t
  • stderr очищается до начала stdout, при использовании файлового регистратора
  • Я хочу поймать STDERR и STDOUT сценария с фоновым запуском
  • Попытка понять синтаксисы перенаправления bash и их выходы
  • Использование find -exec и проблемы с перенаправлением стандартной ошибки
  • как перенаправить вывод ssh в файл
  • Перенаправить bash stdout + stderr в один файл и stderr в другой файл
  • Может ли запущенный скрипт идентифицировать контекст ведения журнала?
  • Что считается «идеальным» в отношении использования stdout / stderr для вывода в разных ситуациях?
  • Linux и Unix - лучшая ОС в мире.