Пользователь
0,0
рейтинг
20 февраля 2012 в 20:40

Администрирование → Что означает "> /dev/null 2>&1"? перевод

*nix*
Долгое время никто не мог объяснить мне, что за амперсанды, знаки < и > и цифры идут после юниксовых команд. При этом все примеры были показаны без объяснения — зачем все это? Гугл также не давал ответа. Особенно заметно использование таких команд во время работы компилятора. В этой статье постараюсь объяснить эти странные команды.

К примеру, у нас есть такая строчка:
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/ перегревает ваш процессор :)
Перевод: Xaprb
@rasa
карма
58,7
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (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
    Я понимаю как оно работает, юзаю много лет, но я так и не понял почему перед дескриптором «откуда» не нужно ставить амперсанд, а перед «куда» нужно. Кто объяснит? :)

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