Что означает «> /dev/null 2>&1»?
Долгое время никто не мог объяснить мне, что за амперсанды, знаки и цифры идут после юниксовых команд. При этом все примеры были показаны без объяснения — зачем все это? Гугл также не давал ответа. Особенно заметно использование таких команд во время работы компилятора. В этой статье постараюсь объяснить эти странные команды.
К примеру, у нас есть такая строчка:
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/ перегревает ваш процессор 🙂
Источник
Что означает «> /dev /null 2 & 1» в этой статье основы crontab? [Дубликат]
У этого вопроса уже есть ответ:
Я читаю статью о crontab
Есть что-то в отключении автоматической отправки писем.
Отключить электронную почту По умолчанию задания cron отправляют электронное письмо на учетную запись пользователя, выполняющую cronjob. Если это не требуется, введите следующие command В конце строки задания cron.
Что такое подробное значение для 2 > & и 1 ? Зачем положить это в конец файла crontab, чтобы отключить отправку электронной почты?
6 ответов
> предназначен для перенаправления
/dev/null — черная дыра, куда отправляются любые отправленные данные
2 — это дескриптор файла для стандартной ошибки
> предназначен для перенаправления
& — это символ дескриптора файла (без него следующий 1 будет считаться именем файла)
1 — это дескриптор файла для стандартного вывода
Поэтому >/dev/null 2>&1 перенаправляет вывод вашей программы на /dev/null . Включите как Standard Error , так и Standard Out .
Более подробная информация доступна на странице перенаправления ввода-вывода на странице документации Linux Documentation .
cron будет отправлять вам только по электронной почте, если есть какой-то результат работы. Когда все перенаправлено на null , выход отсутствует и, следовательно, cron не отправит вам по электронной почте.
/dev/null — это файл устройства, который действует как черная дыра. Все, что написано на нем, отбрасывается или исчезает. Когда вы запускаете скрипт, который дает вам выход, и если мы добавим > /dev/null 2>&1 в конце скрипта, мы просим сценарий написать все, что генерируется из сценария (как выходных, так и сообщений об ошибках), в /dev/null .
Чтобы разбить его:
- 2 — это дескриптор стандартной ошибки или STDERR
- 1 — это дескриптор стандартного вывода или STDOUT
2>&1 запрашивает все STDERR как STDOUT (т. е. обрабатывать все сообщения об ошибках, сгенерированные из сценарий как стандартный вывод). Теперь у нас уже есть > /dev/null в конце скрипта, что означает, что весь стандартный вывод ( STDOUT ) будет записан в /dev/null . Поскольку STDERR теперь переходит в STDOUT (из-за 2>&1 ) и STDERR и STDOUT попадает в черную дыру /dev/null . Другими словами, скрипт отключен.
Кстати, вам нужно иметь > перед /dev/null 2>&1 . Это должно быть:
Это стандартное перенаправление ввода-вывода.
Всегда открываются три файла по умолчанию.
Итак, в этом примере stdout ( 1 ) перенаправляется на /dev/null .
Устройство null — это файл устройства, который отбрасывает все записанные на него данные.
Затем stderr затем перенаправляется в stdout ( 2>&1 ), поэтому оба stdout и stderr перейдут к /dev/null
Таким образом размещение этого в конце задания crontab будет подавлять все выходные данные и ошибки из команды.
Ссылка
Из руководства cron (8) :
При выполнении команд любой вывод отправляется владельцу crontab [â | |].
Итак, что предлагает ваша статья, это не производить вывод, не отправляя почты. Другой способ (более удобный?) Для отключения почты — использовать параметр -m off , т. Е.
Теперь к синтаксису: это специфично для языка оболочки Bourne (и его производных, таких как bash , zsh и т. д.).
будет перенаправлять на дескриптор файла n (или стандартный вывод, если не указано), в дескриптор файла fd .
Дескриптор файла может быть именем файла адреса потока. & — это адресный оператор, как на языке C.
Обычно дескриптор файла 1 — это стандартный вывод (aka stdout ), а дескриптор файла 2 — стандартная ошибка (aka stderr ). Часть
перенаправляет stdout на /dev /null.
перенаправляет поток ошибок в выходной поток, который был перенаправлен на /dev /null. Таким образом, никакой выпуск не создается, и никакая почта не отправляется.
Предупреждение: порядок перенаправления имеет значение:
Попробуйте выполнить эти две команды с непривилегированным пользователем:
В самом деле, в более позднем случае файловый дескриптор 2 установлен на текущий адрес файлового дескриптора « 1 (который в данный момент равен stdout ) и то дескриптор файла 1 перенаправляется на /dev/null . Файловый дескриптор 2 по-прежнему перенаправляется на stdout , независимо от того, что происходит с файловым дескриптором 1 .
Обычно, когда cron выполняет cronjob, он отправляет результат команды, заданной в cronjob, в учетную запись пользователя, выполняющую cronjob. Поэтому, когда ваш cronjob выполняет uptime , например, вывод uptime отправляется пользователю по электронной почте.
Чтобы быть понятным, подразумевается стандартный вывод ( stdout ) команды. Теперь, если вы выполните команду uptime в cornjob следующим образом:
- 2>&1 означает перенаправление chanel 2 ( stderr ) в chanel 1 ( stdout )). Оба выхода теперь находятся на одном канале ( 1 ).
- >/dev/null : означает, что стандартный вывод (и стандартный вывод ошибки) отправляется на /dev/null . /dev/null — специальный файл:
Данные, записанные в нулевой или нулевой специальный файл, отбрасываются.
Итак, вы отбрасываете вывод, и cron не может отправить сообщение.
В справочном руководстве Redirection Bash говорится:
кратко: все сообщения STDERR и STDOUT будут перенаправлены на /dev/null
Источник
Cron не выполняеться из-за > /dev/null
Коллеги , помогите по этому несложному кейсу.
Если не убирать вывод связанный с > /dev/null то вышестоящие команды не выполняются . Подскажите как заэкранизировать.
Зачем скобки? Тебе нечего объединять.
)s — опечатка здесь только?
Наличие root (юзера) означает что это или /etc/cron.d/ или /etc/crontab. Зачем лезть в глобальные файлы, если можно crontab -e
Сделал .Вроде помогает , щас тестим.
Не нужно /bin/bash, сделай как в начале только без скобок. И, да, */1 это то же самое что и просто *
Да ладно: «не умеет перенаправление» .
1. про crontab -e уже сказали.
2. оберните всё в один скрипт.
3. почему именно crond? Проще цикл
Не нужно /bin/bash, сделай как в начале только без скобок. И, да, */1 это то же самое что и просто *
Без скобок не помогало .
Зачем лезть в глобальные файлы, если можно crontab -e
Затем, что потом придёт другой сисадмин, и хрен будет знать, где что искать. Всё верно, важные вещи должны быть в глобальном конфиге, а «crontab -e» — это хоум свой личный бакапить и т.п.
В глобальные кроновские директории пусть пакеты устанавливают свои задания. А рут свои самописные скрипты пусть запускает через личный crontab -e. Если новый админ не знает о crontab -l — он профнепригоден.
Если новый админ не знает о crontab -l — он профнепригоден.
Нет. Профнепригоден тот, кто по укромным кронтабам задания раскладыват.
Ну, ну! «укромные кронтабы» ну ты смешной
Вот и поговорили. 🙂
Но задания в одном месте — это, в любом случае, правильнее. И бакап /etc. Бакап /var/spool выглядит, по меньшей мере, странно.
А мы говорили? Не похоже, что так ведут беседу, больше на нравоучения смахивает.
Как же люди в юниксах то раньше жили без /etc/cron.*/?
Конечно. И началось с «Зачем лезть в глобальные файлы, если можно crontab -e». Как мне показалось. Захотелось вмешаться.
возможно. лучше держать актуальную инфу
Зачем запускать висеть цикл обертывать его в лог и думать как прилепить репорты по почте, если cron уже висит?
Опять не пашет , хотя я привел все к форме (
Опять не пашет , хотя я привел все к форме (
А что пишет-то в лог ? И что за cron ? Правильный cron, кстати, ещё права на файлы проверяет и не будет работать с файлами, к примеру, с правами обычного пользователя в /etc/cron*. /bin/bash тут точно не нужен, должно работать и так:
/bin у check_radius.sh, кстати, тоже не нужно по идее: /bin у root в PATH должен быть.
Vixie cron ( ну то что по умолчанию с дебианом идет) . Без -l -e не пашет , также . В логах ничего нету .
Vixie cron сам обновляет конфигурацию при изменении файлов в /etc/cron.d и делает запись в лог. Если этого нет, он игнорирует эти файлы. Подозреваю, что поможет
Права тоже поменял . Посмотрим седня как он будет пахать
Поучи жену борщ варить.
In general, the system administrator should not use /etc/cron.d/, but use .
если уж пощёл такой разговор, то мне кажется вместо кронкостылей — тут была бы более пригодна директива Restart=on-failure в unit-файле
если уж пощёл такой разговор, то мне кажется вместо кронкостылей — тут была бы более пригодна директива Restart=on-failure в unit-файле
Там же дебиан , который стейбл, в нем пока нету systemd
̈́Эффекта опять нету
In general, the system administrator should not use /etc/cron.d/, but use .
Я тебе тоже могу много инструкций написать c «In general». Сам, и на основе собственного опыта, который, поверь, уже не маленький.
Источник
What does ‘>/dev/null 2>&1’ mean in this article of crontab basics? [duplicate]
I am reading an article about crontab
There is something about disabling automatically sending emails.
Disable Email By default cron jobs sends an email to the user account executing the cronjob. If this is not needed put the following command At the end of the cron job line.
What is the detailed meaning for 2 > & and 1 ? Why putting this to the end of a crontab file would turn off the email-sending thing?
6 Answers 6
> is for redirect
/dev/null is a black hole where any data sent, will be discarded
2 is the file descriptor for Standard Error
> is for redirect
& is the symbol for file descriptor (without it, the following 1 would be considered a filename)
1 is the file descriptor for Standard Out
Therefore >/dev/null 2>&1 redirects the output of your program to /dev/null . Include both the Standard Error and Standard Out .
Much more information is available at The Linux Documentation Project’s I/O Redirection page.
cron will only email you if there is some output from you job. With everything redirected to null , there is no output and hence cron will not email you.
/dev/null is a device file that acts like a blackhole. Whatever that is written to it, get discarded or disappears. When you run a script that gives you an output and if we add a > /dev/null 2>&1 at the end of the script, we are asking the script to write whatever that is generated from the script (both the output and error messages) to /dev/null .
- 2 is the handle for standard error or STDERR
- 1 is the handle for standard output or STDOUT
2>&1 is asking to direct all the STDERR as STDOUT , (ie. to treat all the error messages generated from the script as its standard output). Now we already have > /dev/null at the end of the script which means all the standard output ( STDOUT ) will be written to /dev/null . Since STDERR is now going to STDOUT (because of 2>&1 ) both STDERR and STDOUT ends up in the blackhole /dev/null . In other words, the script is silenced.
By the way, you need to have a > in front of /dev/null 2>&1 . It should be:
This is standard I/O redirection.
There are always three default files open.
So in this example, the stdout ( 1 ) is being redirected to /dev/null .
The null device is a device file that discards all data written to it.
Then stderr is then being redirected into stdout ( 2>&1 ), therefore, both stdout and stderr will go to /dev/null
So placing this at the end of a crontab job will suppress all output and errors from the command.
Reference
From the manual cron(8):
When executing commands, any output is mailed to the owner of the crontab […].
So what your article suggests here is to produce no output, thus sending no mail. Another way (more convenient?) to disable mail is to use the -m off option, i.e.
Now to the syntax: this is specific to the Bourne shell language (and its derivatives such as bash , zsh , and so on).
will redirect to file descriptor n (or standard output if unspecified) to file descriptor fd .
A file descriptor can be a file name of the address of a stream. & is the address operator as in the C language.
Conventionally, file descriptor 1 is standard output (a.k.a. stdout) and file descriptor 2 is standard error (a.k.a. stderr). The chunk
is redirecting stdout to /dev/null.
is redirecting the error stream to the output stream, which has been redirected to /dev/null. As such, no output is produced and no mail is sent.
Warning: the order of redirection matters:
is not the same as
Try these two commands with a non-privileged user:
Indeed, in the later case, file descriptor 2 is set to the current address of file descriptor «1 (which is stdout at this very moment), and then the file descriptor 1 is redirected to /dev/null . File descriptor 2 is still redirected to stdout, no matter what happens to file descriptor 1 .
Источник
