Re: [dev] s - suckless shell

From: <rain1_AT_openmailbox.org>
Date: Fri, 12 Aug 2016 23:51:46 +0100

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!
Received on Sat Aug 13 2016 - 00:51:46 CEST

This archive was generated by hypermail 2.3.0 : Sat Aug 13 2016 - 01:00:14 CEST