Meaning of /dev/null 2>&1 in Crontab’s Cron Job

If you use cron job on Linux, some times you want to ignore the output of the command you executed. This can be done by adding “> /dev/null 2>&1” behind the cron job command.

The command is just work want it should be, but I always curious with what does 2>&1 means. The “> /dev/null” is pretty obvious of what it does without much more explanation, it just redirect all the output to /dev/null which in Linux means we don’t care with the output (or sort of, it’s my own definition).
I tried to search on Google about “2>&1” before, but got no luck, until today I read post at Xaprb post: What does “> /dev/null 2>&1? mean? Which give some explanation about it. Here is a summary of the post:

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.

7 thoughts on “Meaning of /dev/null 2>&1 in Crontab’s Cron Job”

  1. Linux was bulit mainly with the C programming language.

    In the C programming language a program has three data streams which can be handled separately :
    0 means STDIN (STandarD INput) which is usually the keyboard;
    1 means STDOUT (STandarD OUTput) which is the monitor;
    2 means STDERR (STandarD ERRor) which is usually also the monitor by default.

    A program e.g. X by default prints it’s output to STDOUT, to the monitor.
    In the “X >/dev/null 2>&1” statement, the first part “X >/dev/null” redirects X’s output from STDOUT to the /dev/null file which is something like a “bottomless hole” in Linux. What goes there never comes back.
    But X’s STDERR isn’t redirected yet so X’s error messages will still be printed to the monitor.
    The last part of the statement “2>&1” redirects the STDERR (2) to STDIN (1) which is already redircted to /dev/null.
    So none of them prints to the monitor any more.
    (We have to add the “&” sign before the number 1 otherwise STDERR (2) would be redirected to a simple file called 1 in the same directory instead of STDOUT.)

  2. In this line , there is a mistake “The last part of the statement “2>&1? redirects the STDERR (2) to STDIN (1) which is already redircted to /dev/null.” It should be STDERR (2) to STDOUT (1).

    Best Regards,
    Kalin Mandaliev

    1. Kalin is right. STDIN is 0.

      One other point to add. That is the difference between “>/dev/null 2>&1” and “2>&1 >/dev/null”

      As posted above, “>/dev/null 2>&1”:
      – redirects stdout(1) to the file /dev/null
      – THEN redirects stderr(2) to stdout(1)

      The other, “2>&1 >/dev/null”:
      – redirects stderr(2) to stdout(1)
      – THEN redirects stdout to the file /dev/null

      Now, that all sounds reasonable. It also sound like both statements accomplish the same thing…. but they don’t. The assignment of descriptors is absolute. If you assign stdout to /dev/null, then later assignments follow that same path. If you assign stderr to stdout, all stderr messages will go to the stdout device. If you later assign stdout messages to /dev/null, the messages going to stderr will still get sent to the stdout device because “>/dev/null” doesn’t repoint the device, it repoints the stream.

      You don’t believe me. Ok, that;s fine. Bust out gcc and see for yourself and welcome to the funky world of unix descriptors… where 256 is no longer the limit (that’s a descriptor joke).

      flinux:~% cat test.c
      #include
      main()
      {
      write(1, “hello “, 6);
      write(2, “world\n”, 6);
      }

      flinux:~% gcc -o test test.c
      flinuk:~% ./test
      hello world
      flinux:~% ./test >/dev/null
      world
      flinux:~% ./test >/dev/null 2>&1
      flinux:~% ./test 2>&1 >/dev/null
      world

  3. Hey thanks for the info, I’ve been curious about 2>&1 too. I still don’t see the reason why the STDERR is redirected to STDOUT, maybe to prevent linux from logging it!?

Leave a Reply

Your email address will not be published. Required fields are marked *