wow, what a great explanation! (after reading the initial posting, i wondered what does /dev/null do? (which was the question i was going to post.) then i read man "null," and thought, "okay, that's what 'null' does." then i came to mr. trillich's post and really learned a few things. )
sir, if if you're a "second-iteration newbie," i can't imagine what "guru-dome" must be. ...well done. thx. bentley taylor. (potato on 2.2.16) // Will Trillich wrote: > 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. > > -- > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
