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
Received on Tue Aug 23 2016 - 01:37:10 UTC