> So I have a script with the following line after the shebang:
It would help if you'd quote the shebang.
> exec >& file.out
> ## some echo statements after this
> Then I call the script with
> nohup ./script &> /dev/null
I don't understand the &> construct here. Did you mean >&, and
you're using the C shell? If not, what shell are you using to
invoke the script, what shell are you using to run the script, and
what does &> mean?
Under bash, that line would put
nohup ./script
into the background, and treats
> /dev/null
as a command and runs it in the foreground. This makes very little
sense (although a command like > foo.tmp would create the file
foo.tmp, but /dev/null presumably already exists).
> And the echo statements are making their way to file.out.
> So my question is ....
> Woudln't nohup check the script's "initial(i.e. before exec)" status
> of having stdout/stderr being pointed to terminal, and then force the
> script to redirect to /dev/null?
No. Redirections on a command line are a function of the shell,
not nohup (even if nohup is a shell built-in). They take effect
before nohup is executed. nohup's initial stdout and stderr are
pointed at /dev/null.
If nohup's initial stdout/stderr *were* a terminal, nohup would
redirect them to the file nohup.out.
> How is the exec that happens later
> able to override this?
exec is a shell built-in. Any program (here, the shell running the
script) may close stdin, stdout, and/or stderr and re-open it/them
pointing elsewhere, as many times as it wants to. C programs might
use freopen() instead.
