Что означает "> /dev/null 2>&1"?

http://www.xaprb.com/blog/2006/06/06/what-does-devnull-21-mean/
  • Перевод
Долгое время никто не мог объяснить мне, что за амперсанды, знаки < и > и цифры идут после юниксовых команд. При этом все примеры были показаны без объяснения — зачем все это? Гугл также не давал ответа. Особенно заметно использование таких команд во время работы компилятора. В этой статье постараюсь объяснить эти странные команды.

К примеру, у нас есть такая строчка:
cron job command > /dev/null 2>&1



Перенаправление вывода

Оператор > («больше чем»), как в примере выше, переадресовывает вывод программы. В данном случае, что-то отправляется в /dev/null, а что-то переадресовывается в &1.

Стандартные ввод, вывод и ошибка

Существует три стандартных значения ввода и вывода для программ. Ввод получают от клавиатуры (интерактивная, диалоговая программа), или из программы, обрабатывающей вывод другой программы.
Результат программы обычно печатается в стандартной вывод и иногда в файл «STDERR» (ошибка). Все это три дескриптора файла (вы можете представить их как «потоки данных», пришли из языка программирования C), которые часто называют STDIN, STDOUT и STDERR.

Но часто к ним обращаются не по имени, а по номеру:
0 — STDIN, 1 — STDOUT и 2 — STDERR
По умолчанию, если вы не укажете номер, то будет подразумеваться STDOUT.

В нашем примере видно, что команда направляет свой стандартный вывод в /dev/null (псевдоустройство, которое может принять произвольный объём данных, не сохраняя их совершенно нигде, следовательно, подавив стандартный вывод). Затем все ошибки (то есть STDERR) перенаправить в стандартный вывод. Необходимо поставить амперсанд "&" перед номером назначения.

Смысл вкратце — "весь вывод указанной команды спихнуть в черную дыру!".
Это один из способов сделать программу по-настоящему безмолвной. Добавлю, что команда в примере аналогична команде cron job command >/dev/null 2>/dev/null

Официальный FAQ FreeBSD предупреждает: отправка данных в /dev/null/ перегревает ваш процессор :)
Метки:
Поделиться публикацией
Похожие публикации
Комментарии 31
  • 0
    а кто подскажет еще, бывает встречаются /dev/null & или даже /dev/null &&
    • +10
      [command] & — запускает команду в фоне, т.е. управление отдаётся командному интерпретатору (bash, например), а [command] будет выполняться «параллельно».
      [command] && — подразумевает, что следующая команда будет выполнена только в том случае, если [command] была выполнена успешна (вернула 0).
      • +6
        & = Run in background
        && = Logical AND
      • +3
        /dev/null & выполнение в фоне
        /dev/null && после выполнения без ошибок выполнить следующую коменду
        • +16
          man bash.

          Раздел Pipelines
          • 0
            Это тоже необходимо прочитать, но в данном случае — перевод служит скорее целям популяризации *nix
            :-)
            • +2
              И в чем тут популяризация? Я конечно всегда рад *nix, в особенности GNU/Linux, НО тем не менее эти операции не являются экзотикой и для командных сценариев в Windows — 2>nul ping ya.ru>nul
          • +3
            Нда, FAQ по FreeBSD, особенно это дополнение писал человек с юмором.
            • +1
              что команда направляет свой стандартный вывод в /dev/null

              Затем все ошибки (то есть STDERR) перенаправить в стандартный вывод.


              А теперь вопрос — STDERR пойдет за STDOUT в /dev/null, или произойдет магия и STDERR выбухается на консоль?
              • 0
                Нет, ApmeM, вывод STDOUT тоже перенаправлен в никуда. То есть программа не выведет вообще ничего.
                • +1
                  Чтобы произошла «магия» вашими словами, нужно просто поменять местами перенаправления: 2>&1 >/dev/null
                  в этом случае STDERR сначала перенаправится на консоль, а потом STDOUT в /dev/null
                • +20
                  Долгое время никто не мог объяснить мне, что за амперсанды, знаки < и > и цифры идут после юниксовых команд. При этом все примеры были показаны без объяснения — зачем все это? Гугл также не давал ответа.

                  Что эти люди делают в никсах?
                  • +1
                    Видимо тоже что и переводчик долгое время, просто пользовались как десктопом, командный интерпретатор открывали раз в год что бы решить какую-то задачу, подсмотрев решение на форуме.
                    Изначально входной порог в *nix рассчитан на тесную работу с shell'ом, графика просто физически не может быть на столько же удобна и гибка. Хотя без неё многие вещи тоже были бы не очень удобны, хотя, думаю, в таком случае cli развился бы еще сильнее.
                  • +2
                    Есть команда whatis дает быстрое пояснее nix* командам

                    → whatis sed
                    gsed(1), sed(1) - stream editor for filtering and transforming text
                    sed(1) - stream editor


                    смотри также apropos
                    • +5
                      Однако :)

                      image
                      • +11
                        [bison@localhost ~]$ whatis git
                        git (1) — the stupid content tracker

                        O_o
                    • 0
                      В винде с этими 2>&1 всё очень похоже. Собственно, оно и неудивительно, учитывая откуда содрал источники вдохновения создателя ДОСа.

                      Спасибо, не знал такой нюанс, хотя и видел пару раз.
                      • +4
                        >Гугл также не давал ответа
                        Я что-то пропустил в этой жизни? Насколько я помню, ответ это есть на всех никсовых форумах лет 10 как уже, надо было просто поискать.
                        • +1
                          Если автор вбил именно пресловутую строчку в гугл, то до недавних реформ (тепрь все символы заменяются на их названия, "/dev/null" -> «slash dev slash null»), реальный запрос имел бы вид «dev null 2 1», и неудивительно, что он по теме мало что нашел.
                      • +1
                        На хабре статья про базовые навыки работы с юниксовой консолью ушла в минус (на момент публикации комментария -3). Однако
                        • +8
                          Да где тут навыки? Это не формат статьи, а формат форумного ответа. Да и не статья, а перевод записи в блоге :)
                          А статей на эту тему много, при чём толковых, интересных.
                        • +2
                          Кому интересно эти и другие трюки могут почитать www.opennet.ru/docs/RUS/bash_scripting_guide/ там много и подробно. К тому же все по разделам.
                          • 0
                            А вот, кстати, как-то находил отличия в работе с дескрипторами и перенаправляениями вывода между Shell и Bash.
                            Правда забыл в чем была разница… Но помню, что я не могу из shell выполнить что-то, что работало в Bash.
                          • +2
                            Не, автора, конечно, надо похвалить за старание донести до широких масс, но вот с тем, что «гугл не помог» — это перебор. Не раз про это писали на том же linux.ru
                            Правда, то было еще в доубунтовые времена
                            • +1
                              >>Долгое время никто не мог объяснить мне
                              А историю почитать не пробовали?
                              Есть офигенная книга от пионеров UNIX-а, это Брайн Керниган и Роб Пайк «UNIX. Программное окружение». Ничего из написанного в книге не потеряло смысл, разве что иерархия файлов другая, а принципы те же самые!
                              Из современных, есть офигенный мануал «Wiley Publishing — Mastering UNIX Shell Scripting.pdf».

                              Более того если вы интерисуетесь\используте UNIX-подобную, то вам должны быть знакомы фамилии Реймонд, Стивенс.
                              • 0
                                Все что было сказано в статье, и не только, есть в BSDA. Рекомендую данное пособие и начинающим и тем кто уже работал с *nix.
                                • +1
                                  Оператор > («больше чем»), как в примере выше, переадресовывает вывод программы — например, передает его для обработки какому-нибудь оператору Linux.

                                  Это неверно. Оператор > перенаправляет в файл. Передать для обработки дальше это труба "|".
                                  • 0
                                    Спасибо. Убрал эту ошибку из поста.
                                  • 0
                                    Еще есть перенаправление вывода команды оперетором <(), который отличается от |
                                    Пример:
                                    LAST=""; cat file | while read i; do LAST="$i"; done; echo $LAST
                                    Вывод пуст всегда.
                                    LAST=""; while read i; do LAST="$i"; done < <(cat file); echo $LAST
                                    Вывод — последняя строка файла.
                                    • 0
                                      Я понимаю как оно работает, юзаю много лет, но я так и не понял почему перед дескриптором «откуда» не нужно ставить амперсанд, а перед «куда» нужно. Кто объяснит? :)

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.