Where, exactly, is /dev/null? I imagine it as a sort of void, a black hole of the system to which I can banish things, send thoughts into exile. I sent all my mail to /dev/null, this afternoon, due to a forgotten then. You see, if you write a mail filter that says that if such and such save /dev/null and forget the then that should come in between, well, you’re actually going to save every piece of mail you receive to /dev/null. Which is a term so poetic that I completely refuse to look it up and discover its true meaning. Devices, null, nothing, I’m sure I’m close enough.
I found it useful but disconcerting that even though it took me hours to realise that I’d made a mistake (0 emails in five hours is abnormal, it’s obvious) the email was resurrected. I caught the truant then, hammered it into place (with some assistence, I gratefully admit) and checked my mail. And it all arrived.
So where was that mail? Did it come back from /dev/null? Or did it never go there? Surely by rights something once banished should never return?
Rorschach
/dev/null is from the Unix device by that name: in the /dev directory is the “null” device. It is used as the universal bit-bucket and represents — as you noted — a black hole. Anything written to it goes bye-bye.
(Well, it should go bye-bye. Obviously, your /dev/null isn’t working properly. I’d report it to the nearest black hole repair center.)
DOS used this idea as (I believe) dev:null and since Mac OS is now based on Unix it contains the /dev/null device too.
jeremy hunsinger
are you getting your mail from a server? or do you run a mail server? if you are getting your mail from a server, then you probably have ‘leave mail on server’ turned on or maybe the server is imap. if you have that turned on, and are using the correct mail client, then when the local index did not contain the mail on the server, it downloaded the mail again. and since you had corrected your, i’m assuming procmail filter, which was between your client and host, maybe using fetchmail? you could in theory have the result you describe above. However, you should cat together some dead files and mv them to /dev/null and see if they are gone. cause if they aren’t then you have a bad /dev/null which is a common cracker trick.
Jill
Hm. I wrote a filter directly in my account on the unix server that receives my mail, basically it was a .forward file that started with the magic words #exim filter, as described here (descriptions are in Norwegian but with code examples). So the filtering was happening *before* I download it to my personal computer. Which was the point: I wanted a filter so good I wouldn’t even know whether I was not receiving certain emails. If you get my meaning.
It seems to work now. MIght contact my black hole repairsman anyway 🙂
ningBlogger
I have also struggled somewhat in understanding dev/null.
So, you have a certain amount of bytes in memory or on disk that you want to dispose of. Why do you have to send it into nothingness (dev/null)? Why does it not suffice to erase the adress in memory or on disk to these unwanted bytes?
To send something into nothingness is cruel. Just to erase an adress, well that happens all the time in real life.
Jesper Juul
I always considered it to be techie humour – /dev/ is the directory with all the devices such as cdroms and floppies, and it’s pretty funny to have a device that’s “null”, isn’t it?
The practical reason for it’s existence is likely that in many cases you will be running some program that spits out amazing amounts of output, so you’ll type:
bigprogram
But rather than waiting for the output to scroll over your screen you then redirect the output to a file (i.e. it gets written to disc but not displayed):
bigprogram > outputfile.txt
or if you don’t want a file because you really don’t care about the output, then
bigprogram > /dev/null
If there was no /dev/null, every single of the thousands of programs you find in Unix/Linux would need a separate option for suppressing output (which can be a hazzle anyway), so this saves amazing amounts of work.
It’s the power of generalization, it’s very Unix-like, and it’s just so darn beautiful, methinks.
Jill
It is rather beautiful, yes.
Eirik
In /dev/null no one can hear you scream …
Started thinking about /dev/null and where it all came from. Didn’t really find it, but found a nice and orderly site that held a lot of interesting information. Did you for instance know that:
“During the course of a working day, a lot of data is sent to /dev/null. A lot of this could be company sensitive data, that you wouldn’t want lying around when a hacker breaks into your system, or on your system backups (not that many people back up /dev/null anyway). There is also the problem of what happens to all this data that is sent there, sometimes several GigaBytes a day. We need to do something with it, and the second law of thermodynamics, when coupled with quantum theory and information theory will prove that you cannot destroy information. So there is a big pile of information sitting somewhere. Normally computers get rid of this excess information as heat, but these days computers are getting so hot that this isn’t very efficient, and data can hang about. Not to mention the extra electricity used to run the air-conditioning with this extra energy (particularly important in California).
Another problem involving entropy is that of /dev/random becoming bare, and being reduced to predictable pseudo-randomness. There are many security problems that can be caused if Hackers can guess what your computer is thinking. This needs to be stopped, so you should keep a good pool of entropy in your /dev/random. ”
Me either…
So I guess I will try their products 🙂
Ah – yes, you find the company at:
http://www.bitclean.com/product.shtml
kr
Rorschach
/dev/null
/dev/random
/dev/zero
Personally, the last is my favorite. Of course for clearing a disk or a file, /dev/random comes in awfully handy too.
Jesper Juul was mostly correct in the assement as a place to put unwated output. When writing shell scripts, there are times when you don’t want the output at all. Things like testing the return code from “grep” gets really complicated if you can’t dump the output from it. Ah, but redirecting all the output into never-never land (grep blah *.rc 2>&1 > /dev/null) makes it simple!
/dev/null has been around since the dawn of Unix; I’m not sure about the other two. I didn’t check the kernel source but I’m pretty sure that the latest Linux includes a special black hole generator specifically for the purpose of disposing of unwanted bits. Other OSes just turn the unwanted output into socks and then put them into the wash where they conveniently disappear.
As for the original problem and the missing “then” in the exim script, I’m pretty sure that the data wasn’t dumped to /dev/null. I’m going to guess (though I haven’t tried it) that it simply failed and didn’t do anything since it didn’t understand the syntax (“if … what? No Then? WTF? I don’t understand!”). Programs are picky that way.
According to the exim documentation if there’s an error it freezes the message and writes a message to a log file. When you corrected the script, it thawed the message(s) and delivered them. I didn’t see where or the name of the log file in my cursory inspection of the doc so that is left as an exercise to the reader.