[ydl-gen] Sending mail from the command line

[Eric Dunbar]

Muchos gracias for the link Derick.

Saturday morning on the web. That's the perfect time of day since my
wife's still asleep :-).

8.3 answered my questions nicely:

"stdin, stdout, stderr:

Under UNIX, every system component is treated as if it were a file.
Commands and programs get their input from a `file' called stdin
(standard input; usually, the keyboard), put their output on a `file'
called stdout (usually, the screen), and error messages go to a `file'
called stderr (usually, the screen). Using < and > you redirect input
and output to a different file. Moreover, >> appends the output to a
file instead of overwriting it; 2> redirects error messages (stderr);
2>&1 redirects stderr to stdout, while 1>&2 redirects stdout to
stderr. There's a `black hole' called /dev/null: everything redirected
to it disappears;"

On 09/09/06, Derick Centeno <aguilarojo at verizon.net> wrote:
> Good Morning Eric!
>
> I don't intend to speak on Joe's behalf, but there is a reference you
> could address which is available here:
>
> http://www.tldp.org/HOWTO/VMS-to-Linux-HOWTO/advanced-topics.html
>
> When you get to that page scroll down to section 8.3 Files, Revisited.
> I'm sure that these specific questions will be addressed quite clearly
> there.
> Joe is a great fellow, but I think he may be enjoying Saturday morning
> by doing something other than addressing this list.  Humor aside, the
> Linux Documentation Project may be something you may want to keep as a
> link within your browser.
>
> Be well...
>
>
> Eric Dunbar wrote:
> > On 08/09/06, Joseph E. Sacco, Ph.D. <joseph_sacco at comcast.net> wrote:
> >
> >> Eric,
> >>
> >> "> /dev/null 2>&1 " takes any output directed to stdout or stderr and
> >> redirects it to the bit bucket, /dev/null.
> >>
> >> Specifically:
> >> * redirect stdout to /dev/null
> >>
> >>    > /dev/null
> >>
> >> * redirect stderr to stdout
> >>
> >>    2>&1
> >>
> >
> > Q1:
> > So, since it's redirected to a 'bit bucket' (euphemism for garbage
> > can?), does this mean that nothing happens with the redirected
> > information?
> >
> > Q2:
> > Also, where are the stdout and stderr coming from? From the first
> > command (the ls in this case) or from the second command?
> >
> > Q3:
> > In '2>&1':
> > 1. the '2' represents the 'stderr' from ls (or from both)?,
> > 2. the '>' represents 'redirect', and
> > 3. the '&1' means append to 1. What is 1? The first argument passed to
> > the current command (in this case mail)?
> >
> >
> >> A construct like this is often used in a crontab entry.
> >>
> >> -Joseph
> >>
> >
> > <snip>
> >
> >
> >> If you use a construct like this in a crontab file, you
> >>
> >
> > Your thought process ended abruptly?
> >
> > Thanks for the edumacational posts -- I'm learning lots,
> >
> > Eric.
> >
> >
> >> On Fri, 2006-09-08 at 23:17 -0400, Eric Dunbar wrote:
> >>
> >>> On 07/09/06, Joseph E. Sacco, Ph.D. <joseph_sacco at comcast.net> wrote:
> >>>
> >>>> Of course, a pipe should work, assuming sendmail is running. Here is an
> >>>> example:
> >>>>
> >>>>     % ls | mail -s "output of ls"  jsacco > /dev/null 2>&1
> >>>>
> >>> Question time:
> >>>
> >>> What does the "> /dev/null 2>&1" do?
> >>>
> >>> I understand that the | is the 'pipe' and it redirects the output from
> >>> the first command to the input for the second but what do the
> >>> following arguments do?:
> >>> '>'
> >>> '/dev/null 2'
> >>> '>&1'
> >>>
> >>> When I try:
> >>> ls | mail -s "output of ls"  username > /dev/null 2>&1
> >>>
> >>> and
> >>>
> >>> ls | mail -s "output of ls"  username
> >>>
> >>> I get the same e-mail with either command.
> >>>
> >>> Thanks, Eric.