4 ms·
Well, a lot of the power of the UNIX shell comes form this and I see this as a major advantage over Windows. So no, I do not think Windows got it right. Any ki
by uecker 5mo ago
Well, a lot of the power of the UNIX shell comes form this and I see this as a major advantage over Windows. So no, I do not think Windows got it right.
Any kind of replacement should aim for the same conceptual simplicity and power. Sadly, I fear that people driving development nowadays are more interested in building unbreakable walled gardens for advertisement or app stores, or trying to squeeze down the some small gain when used on the cloud. I am more interested in general computing on the user side.
- dcrazy 5mo agoNothing about the UNIX shell is reliant on the fork model. Windows processes have stdio handles as well.
- uecker 5mo agoA lot of features of UNIX shells are build around pipe and dup and the fork + exec model. One can certainly implement in differently, but it is - like UNIX in general - very nice and elegant.
- amluto 5mo agoHelp me out here, please. Off the top of my head, the exec command is dependent on exec, except that a spawn + wait implementation would be a mostly okay substitute. Pipes and redirections don’t need fork + exec. Neither do subshells.
- uecker 5mo agoIf you use pipe() you get two ends in the same process, then you fork and child and parent can communicate. This is how a unix shell setups up pipes and it is rather elegant.
- dwattttt 5mo agoDoing the same thing on Windows, I create the pipe and get two ends in the same process. Then I'd call CreateProcess and indicate I want the pipe's handle (fd) inherited to the child, and I'd use a prearranged way to tell the child what the fd value is it should use. Possibly the most common way to tell the child the value is by setting it as a CLI arg in CreateProcess.
- uecker 5mo agoYes, and CreateProcess needs special facilities to make this possible while in the UNIX model you don't.
- dwattttt 5mo agoWhich special facilities are you referring to? If it's the ability to selectively inherit handles (fds) to a new process, Linux's lack of this "special facility" is nothing to be proud of. How do you selectively pass on fds without having a global impact on your process?
- uecker 5mo agoAs explained above, you fork and then before exec you can use all the usual APIs to close/duplicate/... file descriptors. This has no global impact on the parent process because you are already in the child, but one still has access to all the context of the parent needed to whatever configuration you want to do, including things that will be invented in 20 years and are not even conceived today.
- dwattttt 5mo agoAnd as noted elsewhere, what you want is a new process with a specific fd: duplicating your current process state is a path-dependent evolution, rather than a logic step. There have been plenty of comments here about effective workarounds, multi-process architectures to keep fork cheap, zygotes... these are very specifically working around the problem, while trying to avoid admitting it's a problem.
- IshKebab 5mo agoIt's an elegant hack, but it's still a hack. Not what we should be doing in 2026.
- uecker 5mo agoI would prefer to continue to use elegant interfaces even beyond 2026.
- IshKebab 5mo agoI would prefer to use elegant interfaces that aren't massive hacks.
- uecker 5mo agoDefine "hack".
- IshKebab 5mo agoSomething that works but is a surprising and suboptimal way to do things. I dunno, that's the best I can do for now. Maybe you can do better?
- uecker 5mo agoI don't think it is hack. I think it is a nice and clean API and the hate is largely irrational. I think one could improve usability for multi-threaded programs though.