Originally Posted by carlitos_30
Ok. But what could be the purpose to do that, considering that nothing (for the mere mortal) is inside /dev/null?
It's handy in the event that you need a dummy input. For example, if you have a program that normally requires some input from STDIN, you can redirect /dev/null as an input file in order to trick the program into thinking it has an input.
One example of this kind of trick is inspecting GCC's behavior
; passing /dev/null as an input file allows one to examine quite a bit of GCC's steps in compilation without actually compliling anything.
However, there's a much more important use for this kind of redirection: running a daemon.
See, part of a daemon's operation involves detaching itself from its parent shell process (or some other process it's the child of, like a webserver). Part of this includes detaching itself from said shell by redirecting STDIN, STDERR, and STDOUT to alternate filehandles. /dev/null is commonly used for STDIN, while STDOUT and STDERR may be redirected to /dev/null and/or some logfile.
Most daemons will do this on their own (since most languages support closing and re-opening STDIO filehandles). However, if you're trying to daemonize a program that doesn't daemonize itself (either it's meant to have a controlling terminal or it otherwise doesn't daemonize on its own for some reason), you'll want to make sure that STDIN, STDOUT, and STDERR are detached from the shell. That's where the </dev/null bit comes in.
Note that there are other tasks involved in daemonization, too. However, I imagine this is the context that you'd most often see /dev/null redirected to STDIN.