Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What the hell is /dev/null?
- Thread starter imacintel
- Start date
- Sort by reaction score
Daveway said:
The terminal command usually used is:
yes > dev/null
It instructs the computer to send a continuous stream of y's to the black hole that is dev/null.
You also use it if you don't want to get emails from a cronjob.
I still don't understand why you can't just disable emailing with a simple flag in the cron command...
I still don't understand why you can't just disable emailing with a simple flag in the cron command...
Just guessing what the designers had in mind, but by allowing an arbitrary command as a cron task they made it perfectly general. Since there was already one way to suppress output (directing stdout and stderr to /dev/null), they may have seen no need to clutter up crontab lines with other ways to accomplish the same thing.realityisterror said:
BiikeMike said:
Some commands generate text even if you don't want them to. For instance, if you're running a job that produces errors, you might want to redirect that error output so that you don't see it. You could either put into a file, or if you know you don't want it, you can send it to /dev/null.
Here's a good example that I actually used at work recently. I wanted to search a filesystem for a particular file. The way to do this in unix is:
find / -name <file_name>
This command will print out all files containing the string <file_name>. But at work I'm sharing a system with hundreds of other people, and those people may have locked certain directories so that I can't see what's inside of them. When this happens, the find command write out an error message saying it couldn't look inside such-and-such directory.
In my case, I didn't want to see these error messages, so I used a redirect to send error messages to /dev/null:
find / -name <file_name> 2> /dev/null
The "2>" nonsense just means "redirect error messages to the following place". If I put a file name instead of /dev/null, those messages would go to a file.
BTW, the idea that "yes > /dev/null" somehows races the processor is totally absurd. A processor has many functional units that aren't utilized by yes, AND yes is also IO-bound. Why do people keep spreading this myth?
It's where bits go to die.imacintel said:
So developers can throw away data streams (from any multitude of sources) without having to write special case handlers.BiikeMike said:
Instead, they just stream it (or pipe it, or write it, or whatever) to /dev/null (the "null device", literally) and go on with what they were doing.
/dev/null is also part of the beauty of Unix's I/O "redirection" feature, which lets you mix and match how you want input and output from your programs handled.
When a process runs, it can read from many sources and write to many destinations. By convention three are commonly used, called standard input (stdin), standard output (stdout), and standard error (stderr). Using shell conventions, you can send each of stdin, stdout, and stderr to your screen (the stuff you see in the Terminal window), attach them to particular disk files, use /dev/null (to make the input null or to toss output), attach them to a physical device (like a tape drive), or connect them to another process (which is called piping).
For example, this single shell command
can be used to display the word hello on the screen, store it in a file, make it disappear, send it to a tape drive, or send it to a command named lp that prints it:
and the echo command itself doesn't have to know or care where the output is going.
In this case, the /dev/null choice wasn't very useful, but /dev/null is handy for commands that generate output you don't want this particular time, including cron tasks and the example savar gave. I sometimes redirect the output of the rm command (which removes a file) to /dev/null so I don't see an error message if the file doesn't exist. But other times I do want to see that message because it's a sign of a problem if the file doesn't exist, in which case I don't use /dev/null.
Note: I've purposely avoided mentioning differences among shells in the redirection syntax.
When a process runs, it can read from many sources and write to many destinations. By convention three are commonly used, called standard input (stdin), standard output (stdout), and standard error (stderr). Using shell conventions, you can send each of stdin, stdout, and stderr to your screen (the stuff you see in the Terminal window), attach them to particular disk files, use /dev/null (to make the input null or to toss output), attach them to a physical device (like a tape drive), or connect them to another process (which is called piping).
For example, this single shell command
Code:
echo "hello"
Code:
echo "hello"
echo "hello" >/Users/DoctorQ/Documents/hello.txt
echo "hello" >/dev/null
echo "hello" >/dev/mt0
echo "hello" | lpIn this case, the /dev/null choice wasn't very useful, but /dev/null is handy for commands that generate output you don't want this particular time, including cron tasks and the example savar gave. I sometimes redirect the output of the rm command (which removes a file) to /dev/null so I don't see an error message if the file doesn't exist. But other times I do want to see that message because it's a sign of a problem if the file doesn't exist, in which case I don't use /dev/null.
Code:
rm myfile.txt (error message displayed if file doesn't exist)
rm myfile.txt >/dev/null (no message displayed)