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 <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> 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. _______________________________________________ yellowdog-general mailing list [email protected] http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general HINT: to Google archives, try '<keywords> site:terrasoftsolutions.com'
