This is jpco's fork of the extensible shell. Very little interesting is in the main branch; it just exists to (imperfectly) track upstream. Everything is in other feature branches which target the upstream master branch.

I am primarily interested in developing on the upstream es, rather than forking off my own version; I believe there has been good work happening on es, but because it's mostly all in individual forks, that good work has been fragmented and there hasn't been much real community momentum for years. This is a shame!

Here's a big list of the further development on es I'm interested in, in roughly descending priority. Many of these interact with each other.

• Input extensibility. This is the extensibility that every other shell has completely lapped es on at this point -- and for some shells, like zsh, interactive features are practically the entire selling point of the shell. I recently (see this post) refactored input so that command input is specified in initial.es, but things like programmable tab completion and keybindings are still to-do.

• Job control. Sorry to the job-control haters, but I have been surprised at how many people still use the busted, old job-control branch in the repo, and to me that indicates that people still really care about it. I think those people deserve to have it as a properly-supported set of mechanisms in the shell. I also think my design (see the newjobcontrol2 branch) isn't too disruptive to those who don't want job control.

• Extensible primitives. The set of behavior that can be performed by the es binary itself is quite fixed today, and doesn't need to be. I am picturing that something relatively modest, like a change to the build process and a contrib/ directory, would be sufficient to be quite useful.

• Runtime extensibility. See the es-main branch. I would probably want to merge this into upstream piecemeal; there are a lot of ideas in that change and I'd want to take some real time to carefully design each one. For example, I haven't verified that %run-file as-is can do ignoreeof-like behavior, and I'd also really like to merge $&runfile and $&runstring if possible. (Maybe that would have to be co-designed with the "reader commands" up above.)

• Better error handling. Since es has exceptions, we could (should?) lean on them harder. Ideally the error handling could be good enough that es -e is even a useful default to use in the interactive case. See the throwonfalse branch. (This also intersects with the es-main branch, since throwonfalse can be a runflag.)

• Better locale/UTF-8 support. I think es should internally stay only ASCII-aware, but it should "understand" locales and better support non-ASCII inputs in builtins such as %split (as an example, just try to %split on a multi-byte character!)

Some additional, "nitpicky" changes I may not be able to justify getting into the shell, especially when backwards-incompatible:

• Allowing catch to specify an exception to catch, which would cause all other exceptions to be passed through

• Removing the retry exception

• Changing the precedence of nested subscripts like $$x(2) to be different from $($x(2))

• Changing $x(3 ... 1) to return the first three elements of $x in reverse order

• No longer binding $0 to the name of the currently-evaluating function

• Improving shell syntax to support redirecting from input substitutions, like cmd < <{foo}

• Changing certain builtins, such as umask, to work via settor functions rather than traditional-style builtins

Some "further out" things I haven't messed with yet but which would be interesting to explore:

• General runtime improvements -- switching to a bytecode interpreter, getting tail call optimization, exploring alternative GC strategies, etc. Using bytecode could also make it easier to port es to other (non-exception-using) languages, such as Zig, but that isn't something I'm immediately interested in trying.

• Extending extensible primitives to more thoroughly transform the shell: it could be possible to swap out the fork/exec concurrency model with a pthreads/spawn-based model, which could allow es to run concurrently internally. This would require a lot of refactoring in the shell runtime to allow for multi-threaded code, though.

• Also building on the extensible-primitives idea, further development could be done on the "librarified es" concept. Ideally, "core" es would only require ANSI C, and anything POSIX-y would go in the "library" layer and could be swapped out for something Plan 9-y, or Windows-y, etc.

• Extensible syntax. I have half an idea of how this could be configured in the shell, and 5% of an idea how this could be implemented in the parser. To be honest, I'm a little skeptical of how possible a fully-general solution here is.