The way the shell works is an essential part of Unix design, and the fork/exec pair suits it very well. In the forked child process before the exec, the shell can execute arbitrary code that inherits all file descriptors and manipulates/redirects them in a certain way.
I didn't say it's useless, I said it's a niche utility. There are, what, 10 even slightly commonly used shells?
Compared to the thousands of other programs that spawn processes, I think shells count as a niche use.
If fork() and exec() had been kept as the niche utilities they are in addition to a more commonly used spawn() syscall, fork() and exec() could have remained simple and small, and not needed all the CoW magic and many other complex features at all.
Comments
The way the shell works is an essential part of Unix design, and the fork/exec pair suits it very well. In the forked child process before the exec, the shell can execute arbitrary code that inherits all file descriptors and manipulates/redirects them in a certain way.
I didn't say it's useless, I said it's a niche utility. There are, what, 10 even slightly commonly used shells?
Compared to the thousands of other programs that spawn processes, I think shells count as a niche use.
If fork() and exec() had been kept as the niche utilities they are in addition to a more commonly used spawn() syscall, fork() and exec() could have remained simple and small, and not needed all the CoW magic and many other complex features at all.
I wonder now if one could emulate fork-shenanigans-exec by:
- clone CLONE_FILES with AF_UNIX socketpair
- send file descriptors through the socket
- do whatever was in shenanigans (you have the socket for communication/RPC/whatever)
- exec
or maybe even easier:
- clone CLONE_FILES with pipe or two
- do whatever was in shenanigans (you have the pipe for communication/RPC/whatever)
- exec