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.
