Timeline for Understanding behavior of subshell and stdout with pipe
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 9, 2014 at 0:34 | comment | added | Gilles 'SO- stop being evil' | @RohitRamprasad The fact that foo calls some other program (such as a shell) doesn't change anything. The shell reads from standard input, so it will block if the end of file has not been reached, and return immediately if the end of file has been reached. | |
| Jun 9, 2014 at 0:30 | comment | added | iart | This makes a lot of sense. Thanks! What about the system call to /bin/sh. Shouldn't it also block in the first case? This is the last thing that is confusing me! | |
| Jun 9, 2014 at 0:27 | comment | added | Gilles 'SO- stop being evil' | @RohitRamprasad Standard input, standard output and other file descriptors are inherited by subprocesses. They change only when a process changes them explicitly; for example, the redirection and pipe operators in the shell cause the shell to manipulate descriptors just before invoking the command. | |
| Jun 9, 2014 at 0:20 | comment | added | iart | Ok that makes sense. Does each subshell get it's own standard input stream and output stream? Also in the first case, ./foo calls system(/bin/sh). Shouldn't this sys call block in the first case? Also, why is the stdin of the process ./foo the same as the shell invoked by it? | |
| Jun 9, 2014 at 0:09 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 3.0 |