Re: On the feasibility of a shell that includes execline features

From: Casper Ti. Vector <>
Date: Tue, 23 Aug 2016 09:37:10 +0800

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] <>.
[2] <

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

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC