2017-10-30 13:43:18 +0000, Stephane Chazelas:
[...]
> In any case, that "feature" is not useful. In my experience, I
> more often have to work around it than it comes handy.
>
> I suppose the rationale was that it helped in case stdin was a
> terminal to make sure the asynchronous command did not read from
> it, but the decision to reopen /dev/null in those cases should
> be left to the user as in all other cases it's a pain.
[...]
IMO, the most useful behaviour here is that of zsh that only
redirectes from /dev/null when not explicitely redirected and
stdin happens to be a tty.
(and it has done that from as far as I can remember and I don't
know of anybody complaining about it, while I've answered many
questions on comp.unix.shell or unix.stackexchange.com about
working around the Bourne behaviour).
IMO, the spec should leave it unspecified whether stdin is
implicitely redirected to /dev/null *prior* to other
redirections (pipes not counting as redirections) being applied
when asynchronous.
So an application has to do:
cmd < /dev/null &
if it wants to make sure cmd is redirected from /dev/null.
and:
{ cmd <&3 3<&- & } 3<&0
if it wants to work around that (inconsistent) (mis-)feature of
some shells.
which btw didn't work in the Bourne shell, as $! would not be
available to the parent as the redirection of the compound
command would cause a fork. There (at least the /bin/sh of
Solaris 10, I don't know if that applies to other variants),
you'd need:
start_in_background() {
"$@" <&3 3<&- &
}
start_in_background cmd 3<&0
As redirecting function invocations happens not to fork a
subshell there even if they are defined as compound commands.
--
Stephane
