From owner-freebsd-questions Fri Jun 25 12:43:44 1999 Delivered-To: freebsd-questions@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 39D7114D51 for ; Fri, 25 Jun 1999 12:43:29 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from rainbow5.scientia.demon.co.uk ([192.168.1.2] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.02 #1) id 10xaac-000Dvh-00; Fri, 25 Jun 1999 19:20:38 +0100 (envelope-from ben@rainbow5.scientia.demon.co.uk) Received: from rainbow5.scientia.demon.co.uk (ident=ben) by rainbow5.scientia.demon.co.uk with local (Exim 3.02 #1) id 10xaaY-00012v-00; Fri, 25 Jun 1999 19:20:34 +0100 (envelope-from ben@rainbow5.scientia.demon.co.uk) Date: Fri, 25 Jun 1999 19:20:33 +0100 From: Ben Smithurst To: Scott Worthington Cc: ru@ucb.crimea.ua, freebsd-questions@FreeBSD.ORG Subject: Re: cron difficulties Message-ID: <19990625192033.A3880@rainbow5.scientia.demon.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: > > nameofcommand 2>&1 > /dev/null No, it uses nameofcommand 2>&1 | other command > And again, what makes this form, below, better? > > 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 :-) -- Ben Smithurst | PGP: 0x99392F7D ben@scientia.demon.co.uk | key available from keyservers and | ben+pgp@scientia.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message