Re: The standard input of background processes

[Chet Ramey]

On 5/23/24 6:45 AM, ievojeewai@wilsonb.com wrote:
> Perhaps this is a naïve question, but what is going on with the output behavior
> differences with the example below?
>
>      $ f()(cat); echo dramatic meow | f
>      dramatic meow
>      $ f()(cat&); echo furiously green | f  # no output
>      $ echo trebuchet rockets | (cat&)
>      trebuchet rockets
>      $ f(){ cat&}; echo drop that eel | f
>      drop that eel
>
> I am failing to understand some interaction between functions, subshells, and
> how stdin gets set on background processes.
>
> Note that in dash, only the first example produces output, so it appears that
> _all_ subshells fail to inherit (a copy of?) stdin in this case. Is this
> perhaps specced in POSIX.1-2017 somewhere?

POSIX says

"If job control is disabled (see set, -m), the standard input for an
asynchronous list, before any explicit redirections are performed, shall be
considered to be assigned to a file that has the same properties as
/dev/null. This shall not happen if job control is enabled. In all cases,
explicit redirection of standard input shall override this activity."

So technically in an interactive shell with job control enabled, all those
commands should produce output.

As a practical matter, shells turn off job control in (...) subshells, so
it depends on what you consider an `explicit redirection'. Bash considers
an input pipe to be such a redirection. The second command doesn't print
output because the pipe has already been directed to standard input by the
time the subshell is created. The last command does produce output because
bash optimizes out the fork and it ends up like `echo ... | { cat& }'.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/