[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: howto recreate /dev/null ?



On Thu, Aug 31, 2000 at 08:58:43PM -0700, Jeremiah Hunter Savage wrote:
> Okay,
> 
> This is definitely a newbie question. I keep on reading about sending
> things to /dev/null. So I thought I would give a try:
> 
> mv file /dev/null
> 
> Yes I was root.
> So how do I recreate /dev/null?

hmm. i'm a second-iteration newbie, so i may be off base.
i'll give it a try, anyhow.

are you saying you DO NOT ALREADY have a 'null' entry under
the '/dev' directory? it's hard for me to believe. if you
truly don't have any such item, i'm not sure how to create
it; but it shoula been created when you formatted your
linux/unix system...

what it's for, is this:

say you have a program that generates lots of output
for debugging and so forth, but there's no option to turn
of the verbose data. if you run such a task via cron,
you'll get periodic emails from cron showing you what
output your process generated, even if you're done
debugging it and don't need to see the output any more.

the way we unix/linux folk discard the output from any
process, is to redirect it to /dev/null.

some background, in case you're not up on redirecting:

# mkdir redirect
# cd redirect
# date
Thu Aug 31 23:26:48 CDT 2000
# date > today
#
	note -- there's nothing printed to your console here!
	when we put "greater-than filename" after a command
	we're telling unix point the output from this command
	to that file. redirected!
# ls
today
# cat today
Thu Aug 31 23:26:49 CDT 2000
	so instead of printing the date to our screen, it
	went into the file 'today' which is what we told it
	to do. cool, eh?
# cat < today
Thu Aug 31 23:26:49 CDT 2000
	here, 'cat' just repeats its own input, which is
	now coming from the file 'today'. the > and < act
	as arrows where we can tell linux/unix where to
	get input from, and where to send output to.
# date > today
# cat today
Thu Aug 31 23:26:57 CDT 2000
	as you can see, any "cmd > file" clobbers the contents
	of the file, so anything that had been in there, is gone;
	it's replaced with the output of the command.
# date >> today
# date >> today
# cat today
Thu Aug 31 23:26:57 CDT 2000
Thu Aug 31 23:27:08 CDT 2000
Thu Aug 31 23:27:11 CDT 2000
	using ">>" redirects the printed output to the file
	just as ">" does, but it only APPENDS, leaving previous
	data in the file, as it was. very handy.

back to the /dev/null concept:

# ls -l /dev/null
crw-rw-rw-  1 root  root  1,   3 May  9 21:30 /dev/null

the leading 'c' tells us it's a "character special
file" meaning that linux/unix knows that when something
is directed TO that file or FROM that file, we don't
just read or write -- we do something specific to that
'device'. in this case, READ always returns EOF and
WRITE always disappears as if into a black hole.
if yours is not a 'c'=character-special device, then
you've clobbered it and you'll need help from someone
more knowledgeable than i! (it's probably in a manpage
somewhere, if you can figure out which one...)

what's redirecting to '/dev/null' good for? here's
an example. if you're not running 'fetchmail' as its
own background daemon, to yank your email from various
servers, you can have cron do it for you. the thing is,
you get lots of tripe in the output. it tells you all
about how each message contains X octets, and how it's
downloading the data... none of which you really need.

15 * * * * fetchmail > /dev/null 2>&1

a crontab entry like this will run fetchmail every
hour at 15 minutes past the hour; any printing to STDOUT
will be sent to /dev/null, and with the 2>&1 syntax,
STDERR gets set to what STDOUT is, which means it also
disappears into /dev/null.

moving something to /dev/null via
	mv xyz.pdq /dev/null
may attempt to REPLACE /dev/null with whatever file
that was; if it goes ahead, your 'bitbucket' facility
will be ruined -- /dev/null would just be a file that
you append to and append to and append to!

you can also use /dev/null for STDIN as in
	somecommand < /dev/null
in which case for ANY 'read' that the command does
from STDIN, it'll get EOF forever.



Reply to: