Date: Sat, 26 Jun 1999 22:34:10 -0700 From: "Scott Worthington" <sworthington@hsag.com> To: <ben@scientia.demon.co.uk> Cc: <freebsd-questions@FreeBSD.ORG>, <ru@ucb.crimea.ua> Subject: Re: cron difficulties Message-ID: <s7755568.016@internal.hsag.com>
next in thread | raw e-mail | index | archive | help
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 <ben@scientia.demon.co.uk> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?s7755568.016>