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, <[email protected]> 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
