This is a valid and important point; but I do think the arguments in the `dieshdiedie' (well the name...) page are, though incisive wrt sh(1), mostly unfair to the shell language.
I understand your pursuit of simplicity in the implementation, and agree that the overhead is unavoidable; but let's agree to disagree on whether the overhead is unsatisfying: we are just choosing different balance between implementational simplicity (from the upstream's viewpoint) and linguistic power (from the downstream's viewpoint; and not just saving a few exec()s, really). A similar example of this kind of discrepancy can be seen in [1]: supporting /dev/log as SOCK_STREAM requires delicate handling of fallback issues etc from the upstream, but can enable elegant applications like [2] on the downstream; the musl developer and you just chose different balance on that issue. [1] <http://www.openwall.com/lists/musl/2015/08/10/1>. [2] <http://git.skarnet.org/cgi-bin/cgit.cgi/ s6-rc/tree/examples/source/syslogd-srv/run>. On Mon, Aug 22, 2016 at 10:13:38PM +0200, Laurent Bercot wrote: > So, yes. In a shell you have no choice: you need to be persistent. And so, > if you implement "chain-loading" functions as shell builtins, you may > save a few execs, but the code for your builtins will be significantly more > complex than what they are for instance in execline, because you'll be > duplicating the work of the kernel. No matter how well-designed the "rc" > family of shells is, it's unavoidable and unsatisfying overhead. -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C