Bash – What does “< /dev/null” mean

bash

I understand > /dev/null redirects things to /dev/null which acts like a blackhole. However, I don't understand what < /dev/null means. I saw some script written like this:

nohup myprogram > foo.out 2> foo.err < /dev/null &

So, what does < /dev/null in the code above mean?

here's an example where it's suggested

Best Answer

It ensures that all I/O streams are accounted-for/occupied.

This way, the backgrounded process has nothing "tied" to the terminal so you can go about your business without your program trying to read from TTY, which would cause the terminal to hang.

In this case, since you're launching the process over ssh from a shell script, it's making sure that the script can move along unencumbered.

Related Solutions

Bash – Strange behaviour of uninitialized arrays and unset arrays

You can see the difference with declare -p:

unset foo
declare -a foo
declare -p foo
# prints declare -a foo='()'
foo=
declare -p foo
# prints declare -a foo='([0]="")'

If you want to initialize an empty array, the output of the first declare -p is a good hint on the best way to declare it:

declare -a array='()'

(The declare -a part is probably optional, a simple array=() should work just as well.)

If you want to test if an array has 0 elements, use numeric comparison on ${#array[@]}; don't try to do a test -z on the expansion as won't give the correct result in many cases.

linux cron – Email Only Occasionally Sent on Output and Errors

Upon further testing, I suspect the & is messing with your results. As you point out, &>/dev/null is bash syntax, not sh syntax. As a result, sh is creating a subshell and backgrounding it. Sure, the subshell's echo creates stderr, but my theory is that:

cron is not catching the subshell's stderr, and
the backgrounding of the subshell always completes successfully, thus bypassing your || echo ....

... causing the cron job to have no output and thus no mail. Based on my reading of the vixie-cron source, it would seem that the job's stderr and stdout would be captured by cron, but it must be getting lost by the subshell.

Test it yourself in a /bin/sh environment (assuming you do not have a file named 'bar' here):

(grep foo bar) &
echo $?

Best Answer

Related Solutions

Bash – Strange behaviour of uninitialized arrays and unset arrays

linux cron – Email Only Occasionally Sent on Output and Errors

Related Question