Also, the names of shells conventionally end with
sh, just do go with ssh (which incidentally is not
a shell but ends with “sh” because the full name ends
with “shell”.)
On Fri, 12 Aug 2016 23:48:29 +0200
Mattias Andrée <maandree_AT_kth.se> wrote:
> 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:52:27 CEST