On Fri, 12 Aug 2016 23:51:46 +0100
<rain1_AT_openmailbox.org> wrote:
> On 2016-08-12 22:52, Mattias Andrée wrote:
> > 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.
> >> >
> >> >
> >>
>
> such stupid comments Mattias!
>
>
>
Sorry for thinking it is greedy to use one of
the 26 lowercase 1-character names instead of
letter users choose which commands she wants
to only require one key press to type.
Received on Sat Aug 13 2016 - 00:55:20 CEST