Re: [TUHS] Systematic approach to command-line interfaces

[[ I'm digging through old mail -- my summer has been preoccupied by things that kept me from most everything else, including computing. ]] At Sun, 1 Aug 2021 18:13:18 -0600, Andrew Warkentin <andreww591(a)gmail.com> wrote: Subject: Re: [TUHS] Systematic approach to command-line interfaces That's actually what fork(2) is, effectively -- it sets up a new process that then effectively has control over its own destiny, but only by using code supplied by the parent process, and thus it is also working within the limits of the Unix security model. The fact that fork() happens to also do some of the general setup useful in a unix-like system is really just a merely a convenience -- you almost always want all those things to be done anyway. I agree there is some messiness introduced in more modern environments, especially w.r.t. threads, but there is now general consensus on how to handle such things. I'll also note here instead of in a separate message that Ted's followup questions about the API design and security issues with having the parent process have to do all the setup from its own context are exactly the problems that fork() solves -- the elegance of fork() is incredible! You just have to look at it the right way around, and with the Unix security model firmly in mind. I personally find spawn() to be the spawn of the devil, worse by a million times than any alternative, including the Multics process model (which could have made very good use of threads to increase concurrency in handling data pipelines, for example -- it was even proposed at the time). Spawn() is narrow-minded, inelegant, and an antique by design. I struggled for a very long time as an undergrad to understand the Multics process model, but now that I know more about hypervisors (i.e. the likes of Xen) it makes perfect sense to me. I now struggle with liking the the Unix concept of "everything is a file" -- especially with respect to actual data files. Multics also got it right to use single-level storage -- that's the right abstraction for almost everything, i.e. except some forms of communications (for which Multics I/O was a very clever and elegant design). The "unix" nod to single level storage by way of mmap() suffers from horribly bad design and neglect. -- Greg A. Woods <gwoods(a)acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>