On Fri, 12 Aug 2016 23:51:46 +0100 <ra...@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 <maand...@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 > >> <ra...@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.
pgp8cWhkh1muH.pgp
Description: OpenPGP digital signature
