Hi:

I was able to understand stdout 2 stderr
Example: grep da * 1 > & 2
And the example:
grep * 2 > & 1....from reading this page:
http://www.tldp.org/HOWTO/text/Bash-Prog-Intro-HOWTO

When I had gotten to this example in this example:
stderr and stdout 2 file; I was completely bewildered-
I know rm is remove and (-name core) would be the name of an application but I'm confused-
When and why would I use this command?
Does null mean 'pass in absolute silence?
And; where (-name core) is that where I would type in the name of the application?

Also; the page says "This will place every output of a program to a file. This is sometimes suitable for cron entries (if you want a cmd to pass in absolute silence."

Would the file this is referring to be a file that is associated with a cron job? Not to be confused with the script that would be written for the cron job to run? Right?

-name core tells find to look for files and directories named core.

The command could be routinely used to remove program's core (memory content) dumps which are conventionally named core and are only useful if you know how to examine them to find the cause of the program crashing.

/dev/null is a special file. Anything written to it is discarded. When you read from it you get an endless stream of ASCII NUL characters.

&> redirects the standard output (stdout) and standard error (stderr) to the file that follows &>. AFAIK it does not send "every output" but few programs output more than stdout and stderr.

The technique of redirecting stdout and stderr to /dev/null is useful for cron jobs because cron intercepts any output and helpfully tries to make it available, typically by mailing it to the user that it ran the job for.

Actually, that would be /dev/zero. Reading from /dev/null returns EOF, not an ASCII NUL. Writes to either /dev/null or /dev/zero are discarded.

1 members found this post helpful.

Oops. Thanks for the correction

Thanks for answering my thread; this is hard for me to understand-

With the technique of redirecting stdout and stderr to:
/dev/null (which if I understand should be) /dev/zero....is only useful for cron jobs and cron jobs only?

And you mentioned; "mailing it to the user that it ran the job for" Please elaborate so I can comprehend this if you could with my example:
Anything with rkhunter core would than be deleted?....Right?

EOF you do mean end of file right?

Discarding output would normally be done by redirecting to /dev/null. You could get the same (non-)result by redirecting to /dev/zero, but I can't think of any reason to do that other than being deliberately confusing. Discarding of output is most commonly done in scripts, where a command is being run for a purpose other than displaying that output. On occasion, it's useful in an interactive session as well. For example, if you wanted to find all the files under /etc that contain a reference to "localtime", you might runBut, if you do that as a non-root user the output will be cluttered by complaints about files and directories for which you lack read permission. To see just the output for places where you do have read permission and ignore the errors, you discard stderr:As written, that line has so many errors that it's not going to do anything like what you thought it might, and I have no idea where "rkhunter" came into the picture. You were a bit closer in your original posting:First of all, "& >" (with a space between the two characters) is not the same as the single token "&>" (no space). With the space, the single "&" says to run the preceding command in the background and take the rest of the line as a new command, "> /dev/null", which says to run nothing and redirect its output (of which there would be none) onto /dev/null.

The original code from the HOWTO isn't much better:OK, that's at least syntactically correct, discarding both stdout and stderr from the rm command (Of course, the rm command never writes anything to stdout anyway, but whatever.). Also, stderr from the find command is not redirected, so you could still see complaints about unreadable directories and the like. But, the big problem here is that the output from find is substituted in a way that would make any directory with an embedded space character in its name be passed as two separate arguments to rm. Any shell wildcard characters in a directory name would also be a problem. I'd send a nastygram to the author of that document, but the document is over 12 years old, and the author is probably long gone.

Now the default in a cronjob is to collect any output that, in an interactive session, would have gone to the terminal and, if there is any such output, send it in an email message to the user that scheduled the job. So in this case, any complaints from rm would be discarded due to the redirection, but if there were any messages from find, then a message would be sent.

Yes. In a C program using stdio, the manifest constant is named "EOF" and is defined as -1.

1 members found this post helpful.

Rknichols:

The examples helped me to understand; thank you-

Thanks for the confirmation of "Where I would have read permissions and ignore the errors you discard stderr"
I didn't know-
Also did not know about wildcard characters in a directory name would be a problem-

You said that the default in a cronjob is to collect any output that in an interactive sission would of gone to the terminal (if any output) and then sent to the user that scheduled it-

If there is output that let's say is a 'false positive result' (just an example) (a root kit found from a cronjob running)
than the user would be informed of the output via e-mail?

Making sure I understand as this is not exactly easy to learn; I'm glad for the help-

If the programs or scripts being run as part of a cronjob write anything to stdout or stderr, that output will (by default) be sent in an email message to the user that scheduled the cronjob. Now some programs do alter their behavior when output is redirected somewhere besides a terminal**, but for the most part that email message will contain whatever would have shown up on the terminal.

**For an example of this, compare the output of running

Code:

ls

vs.

Code:

ls | cat

1 members found this post helpful.

I compared the 2 output's like you suggested:

I see the difference in format yet the output is the same.

Thanks

I'll continue to read; study; and learn as much as possible about Bash and Bash scripting.
If I can just get down the principles and the basic's of Bash I'll be satisfied but I don't think I'm there yet.

I'm already having trouble with this page in regard to Looping to Reapeat Commands
http://rute.2038bug.com/index.html.gz
It's my hope to grasp these practices to be able to write my first script.

Back to work

Thanks again!