chiton

Chitons are a sea animal with one of the strongest Shells in the animal kingdom. Chiton, this project, as such is an aim to create a strong shell. When I say "shell", I mean to refer to shells like "bash" and "zsh".

Why?

So why create yet another shell when there is no shortage of any. Like who asked for another one?

Honestly, no one asked for one more shell than my (Vaibhav's) own experience with shells and scripts. I have written a fair share of shell scripts. Zshy is a small set of utilities that I wrote to make my life easier. It is a smaller part of what I did on that front (writing Shell scripts).

Overly dependent on installed tools

Over the years I have realized that if a script, or a command depends on reading or writing files, or making a network request, or parsing a YAML or JSON file or network response, the dependency of having proper tools, and their correct versions installed shoots up and that is where your script can turn to a mess.

Some things that scripts might want to do (in different situations):

1. Download and run something on the computer. In such cases, we do something like this currently: curl -fsSL "https://forge.techrail.in/techrail/somerepo/raw/branch/main/install.sh" | zsh
2. Call a network method (such as a POST call to another server to upload a file)
3. Read a file and parse each line to search for some expression.
4. Parse a JSON file which might contain some settings for another tool.
5. Zip, Tar, Gzip a folder; or Unzip, Untar, Un-gzip a file.
6. Write an expression to parse a tabular output from some tool (SQL Query output, ls, kubectl etc.)

While a standard Linux installation has most of the tools, that's not always the case. One notable exception would be a container. You can't always just install a new tool inside a container because they are ephemeral in nature and yet, sometimes you need those features inside a container to debug a problem.

Some things are just painful

In addition there are certain things that are either pretty painful to debug despite the features working properly, OR, a few things that you wish was possible. Examples include:

• You wrote a file which gets called from your startup script and sets up a environment variable but now you don't remember where it was kept. How do you figure out where that file was that set this environment variable?
• Allow a third party tool or an invoked sub-shell to alter the environment of the caller (easily enough, with security).
• Take care of its own as well as other tools' settings (config) in a simple, maintainable, shareable fashion.
• Be able to save the output of a command AFTER it has run.
• Create sessions for certain work, where each session had its own environment setup, history file and settings (e.g. one is a production kubernetes environment, another is a golang development setup, another is a log-viewer environment and so on.)

Shell is hard!

And then there is the Shell programmability problem. The shell scripting language limits you severely. You can't have nested arrays. Simple mathematical expressions can become extremely difficult to express. You cannot have a variable which has a strict data type. So I can set MY_VAR=true and it would mean it is still a string, not a boolean.

Writing shell scripts made me realize that shell scripts are pretty arcane compared to regular scripting languages. While the majority of functionality of a shell is to read a command and show the output, the requirement of piping the output of one tool to another takes you on a path which leads to the requirement of creating a grammar that evolved into the complex beast that it is.

Having fun(ctionality)

Chiton as a shell would try to fix most of that.

Status

It is still a "concept".