On Fri, Dec 07, 2001 at 11:07:22AM +0000, Mark Sheppard wrote:
> On 2001-12-07 (Friday) at 09:46:26 +0000, Paul Roberts wrote:
> > On Thu, Dec 06, 2001 at 11:56:33PM +0100, Cliff Sarginson wrote:
> > > Cron will mail the standard output and error to you by default.
> > > Try appending the following to the end of the cron command:
> > > 
> > >         2>&1 >/dev/null
> > 
> > If i'm not mistaken, this will result in no output. Append this on the
> > end instead to still be mailed errors (if any):
> > 
> > 1>/dev/null
> > 
> > (in fact, the 1 is not even required, its the detfault). File
> > descriptor 2 is stderr, which is where errors should be dumped.
> 
> Actually both will work although yours is probably the better one to
> use (shorter and less confusing).
  
Less confusing to who ?
Only to those who do not care to understand how share redirection
works. Actually it is more confusing. Unless you regard obscurity
as being better.

>In Cliff's answer stderr gets
> redirected to where stdout was going (which is superfluous in this
> context), then stdout gets redirected to /dev/null.  To redirect both
> stdout and stderr to /dev/null you'd have to reverse the order:
> 
>   >/dev/null 2>&1
Whooaa. That is not what he was asking.
He was asking how to get errors without getting "normal" output.
Stderr will be duplicated to stdout, which is where piped output
will go to. Next stdout is redirected to /dev/null, effectively
closed. This means errors will still go down a pipe, normal output
will go to the bit-bucket.
Now in "cron" it may be that this is sorted out for you.
But as I said there are many versions of cron.

Not only that but mine allows you to pipe to anything you care
to.

Mine will work whatever, and can be verified outside of 
cron.

-- 
Regards
Cliff


Reply via email to