From owner-freebsd-questions Mon Jun 28 5:16:16 1999 Delivered-To: freebsd-questions@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id 338A815410 for ; Mon, 28 Jun 1999 05:15:09 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id ; Mon, 28 Jun 1999 14:18:11 +0200 Message-ID: <55586E7391ACD211B9730000C11002761796AD@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: 'Scott Worthington' , ben@scientia.demon.co.uk Cc: freebsd-questions@FreeBSD.ORG, ru@ucb.crimea.ua Subject: RE: cron difficulties Date: Mon, 28 Jun 1999 14:12:18 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Scott Worthington [SMTP:sworthington@hsag.com] > Sent: Sunday, June 27, 1999 7:34 AM > To: ben@scientia.demon.co.uk > Cc: freebsd-questions@FreeBSD.ORG; ru@ucb.crimea.ua > Subject: Re: cron difficulties > > You are absolutely right, I was in error. > > The correct form for it to work is: > > nameofcommand >/dev/null 2>&1 > > I tested my first suggestion, and it does > not work--the above command for the > crontab will ensure that both std out > and std error both go to /dev/null. > > Thanks for the excellent explaination below. [ML] A nitpick, but I see it as neccessary. The below explanation was wrong. The shell does dup/close redirection in order listed. >/dev/null 2>&1 redirects stdout to /dev/null, and then makes a copy of it and assigns it to the stderr, so that both outputs go to the same file, using the same file pointer (important, even though not for /dev/null) >/filename 2>/filename redirects also both outputs to filename, but with different file descriptors resulting in possibly overwriting contents. >>/filename 2>>/filename would have worked but would not have overwritten the file in the first place. 2>&1 >/dev/null copies the stdout and assigns the stderr to it, and then redirects the original stdout to /dev/null, resulting with stderr output going where stdout used to be because it is a copy of the original stdout. /Marino > I'm always learning something new--this is > a great forum. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message