Return to BSD News archive
Xref: sserve comp.unix.bsd.misc:100 comp.unix.questions:66187 comp.unix.bsd.bsdi.misc:335
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.sprintlink.net!cs.utexas.edu!uwm.edu!vixen.cso.uiuc.edu!news.ecn.bgu.edu!feenix.metronet.com!fohnix.metronet.com!not-for-mail
From: tye@fohnix.metronet.com (Tye McQueen)
Newsgroups: comp.unix.bsd.misc,comp.unix.questions,comp.unix.bsd.bsdi.misc
Subject: Re: redirection didn't work in cron
Date: 2 Jul 1995 23:24:32 -0500
Organization: Texas Metronet, Inc (login info (214/705-2901 - 817/571-0400))
Lines: 47
Message-ID: <3t7re0$6fb@fohnix.metronet.com>
References: <3svhg3$ck0@news.mtu.edu> <VIXIE.95Jun29205021@gw.home.vix.com> <3svvur$7gc@miso.wwa.com> <3t21la$1fd@tools.near.net>
NNTP-Posting-Host: fohnix.metronet.com
) >vixie@gw.home.vix.com (Paul A Vixie) wrote in
) >| I suspect that it's telling you there is no "root" command.
)
) dattier@miso.wwa.com (David W. Tamkin) writes:
) >It very well might be, but shouldn't the shell that cron invokes be
) >delivering that message (that there's no "root" command) to stderr, and
) >isn't stderr pointed to /dev/null?
)
barmar@nic.near.net (Barry Margolin) writes:
) Redirection applies to the output of the command, not the shell. If the
) shell has trouble invoking the command in the first place, it sends the
) error to its own stderr. This is why Paul's example of using a subshell
) suppresses the error message: the subshell's output is redirected.
) However, if the shell has trouble forking the subshell you could still get
) an error (although if the system is having trouble forking, it probably
) won't be able to spawn the mail process, either).
This depends on your shell. For ksh:
$ bar >fu 2>&1
$ more fu
/usr/bin/ksh: bar: not found
It appears that /bin/sh tries to predict whether the exec*(2) will
succeed before performing the redirection. I say this because:
$ rm -f fu
$ bar >fu 2>&1
UX:sh: ERROR: bar: Not found
$ more fu
fu: No such file or directory
and I find my explanation more likely than /bin/sh removing "fu"
after the exec*(2) fails. As further proof, you can make /bin/sh
fail in its prediction and thus act like ksh:
$ echo '#!/none/such' >bar
$ chmod +x bar
$ ./bar >fu 2>&1
$ more fu
UX:sh: ERROR: ./bar: Not found
So /bin/sh may or may not redirect the "bar: Not found" error.
/bin/ksh always does. YMMV, of course.
--
Tye McQueen tye@metronet.com || tye@doober.usu.edu
Nothing is obvious unless you are overlooking something