Sorry for replying before reading, but I don't think a
single-character name is a good idea. Two-characters
should also be avoided, but it's acceptable. The number
of available names are severely limited and introduces
an unnecessarily high risk of collision. Short names,
and single-character name in particular, are best left
for user-defined aliases.
I will probably not read this message, because
writing another shell is not on my priority list.
On Fri, 12 Aug 2016 22:41:16 +0100
<rain1_AT_openmailbox.org> wrote:
> Hello!
>
> 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.
>
> With that out the way here's an overview of how it works:
>
> Tokenization [tokenizer.c]: Instead of the strange and
> complex way that normal shells work (where "$X" is
> different to $X for example) s works by a strict tokenize
> -> variable expansion -> parse -> execute pipeline. This
> makes it much easier to program with and less likely for
> scripts to break simply because your CWD has a space in
> it.
>
> Variable expansion [variables.c]: The expander supports
> both $FOO and ${FOO} syntax, it just resolves environment
> variables.
>
> Parsing [parser.c]: There are just 3 binary operations |,
> && and || and '&' optional at the end of a line. There is
> no "if" or looping or anything. parser.c is 85 lines of
> code and uses my region [region.c] based allocator to
> simplify teardown of the structure when it needs to be
> free'd.
>
> [interpreter.c] The interpreter is a simple recursive
> process that walks the AST, creating pipes and forking
> off children.
>
> [supporting/*.c] Instead of redirection operators like <,
> > and >> being part of the language they are simply
> > provided as supporting programs
> that should be added to the $PATH: < is basically just
> cat. The redirection operators are all packaged together
> in busybox style. Similarly glob is not part of the
> language, it is a 20 line script instead. You use it like
> this: glob rm *py
>
> [builtins.c] Of course a shell cannot do everything by
> external tools - so the builtins cd, source, set, unset
> are provided (and treated specially by the interpreter).
>
> It can run scripts you supply, shebang works, using it in
> a terminal interactively works. In theory enough for
> practical every day use.
>
> Except for the low linecount (it is even smaller than
> execline) and simplicity of the lexical aspect of the
> shell language it does not have strong benefits over
> existing shells (especially since it is not POSIX
> compatible) but I hope that the code may be interesting
> or refreshing to others who are unhappy with the excess
> of bloat most software has.
>
>
Received on Fri Aug 12 2016 - 23:48:29 CEST