Hacker News Reader

Comment by dataflow | Hacker News Reader

Interesting, but how would the subprocess understand the resulting FDs? Doesn't that mean you can't really launch a subprocess that doesn't cooperate? In particular, A launches B, and B launches C, then C would have no idea what the FD numbers represent unless B somehow actively receives that information from A through some custom mechanism and communicates that information to C... right? So if B is a random general-purpose process (say, a Bash or Python process) then you're out of luck? Unless I'm missing something.

View on HN

I think there are two kinds of transitions:

- on fork, you are by definition implicitly cooperating with the parent as you are the same software image as the parent; in the case of transitive forks you can be expected, I think, to continue cooperating.

- on exec, you move from implicit cooperation to the need for explicit cooperation, through some kind of interface contract; e.g., the BASH_XTRACEFD environment variable. It is incumbent upon you to hide the good silverware before making the exec transition, as exec is a trust boundary; like when you sell your house, you don't get to control what the new owner of the process does with it, except through kernel-enforced mechanisms like privileges and resource controls and so on.

I think you're introducing complexity into the discussion that isn't relevant. All I'm saying is if you do something like

  (rm -f /run/lock/temp && exec 5<> /run/lock/temp && echo test123 > /run/lock/temp && perl -e 'system("bash -c \"cat /dev/fd/5\"")')

it needs to work fine, and this shouldn't require any particular cooperation between Perl and Bash.

FDs need to be inherited correctly... just like environment variables already are.

Every explicit or implicit redirection in that shell line is basically a call to dup2. At its core, the shell command line processor is effectively[1] a trivial interpreter loop that maps each successive token or group of tokens to fork, exec, open, or dup2. This is what makes fork/exec elegant as compared to CreateProcess; it's just not apparent unless you appreciate how the parts are intended to work together and what they can accomplish.

[1] It's literally a small, trivial loop in the original Bourne shell source code. In modern shells job control and other niceties require additional bookkeeping, but those aren't necessarily implicated in your example. I don't have a URL at hand for that source file, but I did find it last year or the year before, so it shouldn't be too hard to find if you're curious.

I'm sorry, I 100% disagree. A trivial interpreter loop requires fewer lines of code with fork/exec than CreateProcess, therefore the former is more elegant? It might make sense to judge artistic works that way, but is that really the correct yardstick for judging the engineering of a system by anyone other than a CS 101 student tasked with writing a basic REPL? That's like saying adding 2 numbers with my abacus is easier than with your calculator, therefore my abacus is more elegant than your calculator.

Reply on news.ycombinator.com