Re: [dev] s - suckless shell

From: Connor Lane Smith <cls_AT_lubutu.com>
Date: Sat, 13 Aug 2016 12:31:34 +0100

Hi,

I'm not quite sure about this specific design, but I do think there is
still work to be done in shell design. We've not quite got there yet,
I think.

On 12 August 2016 at 22:41, <rain1_AT_openmailbox.org> wrote:
> 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.

Is there no support for 'splatting' a string into several strings? rc
has a coherent approach to this, in that each variable is not a string
but a list of strings. 'Splat' should be supported, but only when done
explicitly.

> Variable expansion [variables.c]: The expander supports both $FOO and ${FOO}
> syntax, it just resolves environment variables.

Fair enough, I think non-environment variables are probably a mistake,
at least so long as they're not easily distinguished.

But I think functions and aliases (which I take it are also missing)
are the greater evil, since they are not first-class: `xargs ll` will
not work if `ll` is a function or an alias. If such things are to
exist, they must also be able to be found in $PATH, some way or
another. They are a real wart on shell languages.

> 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.

Fair enough, I think loops and the like might as well be done by
separate programs. We've even got higher-order functions like xargs.

> [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

I'm not sure how I feel about glob being separate, but I can see how
it might be a good idea.

IO redirection being done by separate programs, though, seems like a
wrong decision. Streaming the data through a separate process is
considerably less efficient than just setting a file descriptor to an
open file, and not always equivalent in behaviour either. For example,
`tty < $TTY` is obviously very different to `cat $TTY | tty`. In my
opinion this is a bug in your design, and needs to be fixed.

In general, I appreciate the idea of slimming down the shell into a
minimalistic language, since I think shell languages have a tendency
to bloat, which is particularly bad when you start having to escape
everything, like bash's bloody exclamation mark (in double-quoted
strings, no less!). I think what's particularly useful about a very
slimline shell like this is that we could potentially use it to try
out new features that aren't in traditional shells, rather than
assuming that those shells got it right. I don't think I'd like to use
this particular shell language in everyday usage though, but I could
see it being nice for shell scripts, where the lack of features might
well be a feature (as there's less to go wrong).

I do agree though that 's' is a bit of an unfortunate name, and rc is
not as bloated as you made it out to be. But I hardly think that rc is
the be-all and end-all of shells.

Thanks,
cls
Received on Sat Aug 13 2016 - 13:31:34 CEST