Re: [dev] s - suckless shell

From: Ben Woolley <tautolog_AT_gmail.com>
Date: Sat, 13 Aug 2016 20:50:03 -0700

> On Aug 13, 2016, at 9:26 AM, Wolfgang Corcoran-Mathe <wcm_AT_sigwinch.xyz> wrote:
>
> Hi rain1,
>
> Quoth rain1_AT_openmailbox.org:
>> GNU Bash is 138227 lines of code. I wrote a simpler shell* in 800 lines: https://notabug.org/rain1/s/
>>
>> *It is not a true POSIX shell. You can't run existing scripts with it. It's technically just a command interpreter.
>
> A point of design philosophy.
>
> While I appreciate the attempt to create a minimal shell, I don’t
> believe this is worth the sacrifice of generality. A shell without
> builtin I/O redirection, control flow, non-environment variablew, etc.
> is crippled as a scripting language.
>

The built-in status of a feature is only significant in its crippling effects. As those crippling effects are removed, the built-in status loses its significance.

> Writing a C compiler would be much easier and would require far less
> code if we used a tiny subset of C.

People have been doing that with success for years.

> We could simplify grep(1) by
> pulling out regular expressions, or sed(1) by having it handle only
> s/// commands. But in each case there would be a new, less general
> tool to learn whose only reason for existence is a lower line count.
>

Those tools are already minimal, and actually the patch command can be thought of as a minimal sed. The support of sed for such uses is actually being dropped from projects because it is too dangerous. So that is a bad example.

> Bloat is not measured in SLOC, but in the deviation of the design from
> the tool’s true use. Traditional shells are system automators as well
> as command interpreters, and much of their usefulness and longevity
> comes from this generality. You might complain about the bloat of sh,
> but I doubt that a shell language stripped of excess could be much
> simpler than rc(1) without sacrificing most of what makes shells
> useful.

We now have very good automation tools that are not shells, like Python and Lua, so wouldn't it make sense to take a second look at shells that are more specific to command interpretation?

Especially since these days we have things like pledge(), and the separation can come with nice side benefits. We already have occasions for restricted shells. I think it would be nice to build them up from something, rather than rewriting from scratch every time.

> Regards,
>
> --
> wcm
>
Received on Sun Aug 14 2016 - 05:50:03 CEST

This archive was generated by hypermail 2.3.0 : Sun Aug 14 2016 - 06:00:16 CEST