exec vs. nohup

[Kenneth Bull]

So I have a script with the following line after the shebang:

exec >& file.out
## some echo statements after this

Then I call the script with

nohup ./script &> /dev/null


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? How is the exec that happens later
able to override this?

Thanks

[Rainer Weikusat]

Because it happens later: The shell which executes the nohup
... redirects file descriptors 1 (stdout) and 2 (stderr) to
/dev/null. Then, the script is executed which redirects the same two
file descriptors to file.out. Hence, output goes to this file.

[Gordon Burditt]

> 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.

[Måns Rullgård]

gordon...@burditt.org (Gordon Burditt) writes:

>> 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?

He's probably using bash. In bash, &>foo is shorthand for >foo 2>&1.

--
Måns Rullgård
ma...@mansr.com

[Rainer Weikusat]

gordon...@burditt.org (Gordon Burditt) writes:
>> 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,

bash

> what shell are you using to run the script, and what does &> mean?

Same as >&: Redirect stdout and stderr. The manpage refers to &> as
'preferred'.