[dcrazy]

Nothing about the UNIX shell is reliant on the fork model. Windows processes have stdio handles as well.

[uecker]

A 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.

[IshKebab]

It's an elegant hack, but it's still a hack. Not what we should be doing in 2026.

[uecker]

I would prefer to continue to use elegant interfaces even beyond 2026.

[IshKebab]

I would prefer to use elegant interfaces that aren't massive hacks.

[uecker]

Define "hack".

[IshKebab]

Something 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?

[amluto]

Help 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]

If 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]

Doing 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]

Yes, and CreateProcess needs special facilities to make this possible while in the UNIX model you don't.

[dwattttt]

Which 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?