Timeline for Understanding file descriptors and pipes resulting from `cat <(<command>)`
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 18 at 12:51 | comment | added | ilkkachu |
It's not likely a temporary process as such, since exec replaces the program code (and everything) within the same process, so e.g. your PID 63813 probably was bash to begin with, for a moment. (Would need to check the code or strace the shell to make sure. But I think that's how it goes.)
|
|
| Aug 18 at 12:51 | comment | added | ilkkachu |
@TheQuark, right, the interactive shell likely forks a copy of itself to set up any redirections, and then exec's the main program (cat), replacing itself. With cat < somefile that setup is just opening the file to fd 0, but with the process substitution it needs to fork another copy of itself to handle the inner command. So the process substitution shell ends up a child of cat (after the exec), and cat gets the fd 63 from the shell program.
|
|
| Aug 18 at 10:33 | comment | added | The Quark |
Mm... So, looking into the process folder of the "root" bash process (63055) in either case (with sleep or with read), I cannot see any file descriptor open on the pipes. So now I am not sure of my understanding that cat "inherits" its fd 63. Is it rather that this fd 63 is "added" to its list of fd's from the mere presence of the <(...) term in the command line? Or is it that cat indeed inherited its fd 63, but from a temporary bash child process, in which the fd 63 was first added/created, and which later on became replaced altogether by its cat child process?
|
|
| Aug 17 at 16:37 | vote | accept | The Quark | ||
| Aug 17 at 15:55 | history | edited | ilkkachu | CC BY-SA 4.0 |
added 53 characters in body
|
| Aug 17 at 15:41 | history | edited | ilkkachu | CC BY-SA 4.0 |
added 139 characters in body
|
| Aug 17 at 15:35 | history | answered | ilkkachu | CC BY-SA 4.0 |