> On Aug 13, 2016, at 9:26 AM, Wolfgang Corcoran-Mathe <[email protected]> 
> wrote:
> 
> Hi rain1,
> 
> Quoth [email protected]:
>> 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
> 

Reply via email to