Re: Synchronous vs. Asynchronous

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 21,  7:41pm, Peter Stephenson wrote:
}
} "external_command > >(blah)" apparently executes "blah" asynchronously
} is because it forks "external_command" before starting the process
} substitution.

Ah, I should have thought of that.

} So there's no chance of >(blah) grabbing the terminal when it
} shouldn't because it's already associated with a job that's
} disconnected from the terminal [...]
} (If it tried to talk to the terminal, having
} already been forked, the job would be stopped by SIGTTIN, so you'd find
} out straight away --- I think that would indicate in this case that the
} logic was screwy rather than what we were trying to do was wrong,
} however.)

Hm.

schaefer<515> /bin/echo >>(tty 0<&1)
/dev/ttys001
schaefer<520> /bin/echo >>(cat 0<&1)
cat: stdin: Input/output error

In neither case is there a SIGTTIN, so there's something wrong with this
analysis.  Nevertheless ...

} The change I made simply means it grabs the terminal when it
} should, which is when it's in the foreground and there was no fork

... that seem likely correct, because withOUT your patch:

schaefer<525> : >>(trap "print Nyah nyah" TTIN; cat 0<&1)
cat: stdin: Interrupted system call
Nyah nyah

Without the trap, I get a silently stopped process with no way to bring
it to the foreground, which becomes a zombie if I SIGTERM it.  So there
definitely is an argument for having *something* wait for those process
substitutions.

} That's the case of >(...) as an ordinary(**) command line argument

Oops, just misconstrued this in my response to Vincent.

} I think the difference must be because with >(...) we add the PID to our
} job table of things to wait for

I'm not sure that's true.

schaefer<537> : >(trap "print Nyah nyah" TTIN; cat 0<&1) 
cat: stdin: Interrupted system call
Nyah nyah

Here again, if I omit the trap then I end up with a zombie cat.  (That
sounds like a line from a low-budget horror flick.)  Nothing's waiting.

} I'm tempted to back off the change for non-redirection process
} substitution and attack that separately, and commit the remaining
} shebang.

I tentatively agree, but confess I've lost precise track of what the
end result is.

} (**) "the case of >(...) as an ordinary command line argument": This
} reminds of a sketch I can vaguely remember of a gorilla travelling on
} the Tube (London Underground to overseas visitors) and everyone ignoring
} it.  It might have been Monty Python.  Or I might just have invented it.

About 3:30 into this:  http://www.youtube.com/watch?v=Px_4JxrIVHc