From owner-freebsd-questions Sat Jun 26 22:32:14 1999 Delivered-To: freebsd-questions@freebsd.org Received: from gate.hsag.com (gate.hsag.com [209.180.144.14]) by hub.freebsd.org (Postfix) with SMTP id 41DC714A2F for ; Sat, 26 Jun 1999 22:32:04 -0700 (PDT) (envelope-from sworthington@hsag.com) Received: (qmail 9590 invoked from network); 27 Jun 1999 05:23:13 -0000 Received: from unknown (HELO internal.hsag.com) (192.168.83.9) by 192.168.83.5 with SMTP; 27 Jun 1999 05:23:13 -0000 Received: from AZPRO-Message_Server by internal.hsag.com with Novell_GroupWise; Sat, 26 Jun 1999 22:34:16 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Sat, 26 Jun 1999 22:34:10 -0700 From: "Scott Worthington" To: Cc: , Subject: Re: cron difficulties Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. I'm always learning something new--this is a great forum. <<< Ben Smithurst 6/25 12:46p >>> Scott Worthington wrote: > The default distribution of FreeBSD uses the below mentioned form > for cron'ing of the /etc/daily, /etc/weekly, and /etc/monthly shell > scripts: >=20 > nameofcommand 2>&1 > /dev/null No, it uses nameofcommand 2>&1 | other command > And again, what makes this form, below, better? >=20 > nameofcommand >/dev/null 2>&1 The fact that the above form, `cmd 2>&1 > /dev/null', doesn't work in FreeBSD's /bin/sh? (Assuming you want to redirect stderr and stdout to /dev/null, and also assuming my tests were correct.) I think the "> /dev/null 2>&1" form first redirects standard output to /dev/null, by closing fd 1, then opening "/dev/null", which will come out as fd 1. Then, it dups (see the dup2(2) manpage) stderr onto stdout, so both go to the same place. It seems the "2>&1 > /dev/null" form first does the dup, so that stderr goes where stdout is (the user's terminal, for an interactive shell), and redirects stdout to /dev/null after that, but stderr remains unchanged, since fd 2 is never touched after the dup (the redirection just closes fd 1, so fd 2 stays as it was). The "2>&1 | other command" form is different, since the output is going to another command and not a file. I'd guess the pipe() is done, then a fork() for each process in the pipeline, and by default (no "2>&1") just stdout is dup'd onto the write end of the pipe in the child process for the first command, which will be read from the read end of the pipe by the child process for the process being piped to. Then, if "2>&1" is there, stderr is dup'd onto stdout, in the child process for the first command of the pipe, so that ends up writing to the pipe as well. This may all be hideously wrong, but as I say, it seems to make sense with my understanding of these things. If anyone thinks I'm talking rubbish, please tell me so :-) --=20 Ben Smithurst | PGP: 0x99392F7D ben@scientia.demon.co.uk | key available from keyservers and | ben+pgp@scientia.demon.co.uk =20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message