Re: howto recreate /dev/null ?
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 debian-user-request@lists.debian.org < /dev/null
Reply to: