back to xoc3.io

2022-05-01 - the ax shell v0.1

i wrote up an idea for a new unix shell a month ago. since then i have refined the idea more. you can see my original iteration here:

the ax shell proposal

reach out to me here if you have feedback: alan@xoc3.io

overview

the ax shell (pronounced "axe" or "acks") is an acronym for "[a]n e[x]treme [shell]". this shell strives to take the unix philosophy to the extreme. doing so means that many posix shell standards are ignored. here are a few of the design highlights of ax:

"straight forward syntax". the entire syntax should be reasonably easy to memorize. this is very unlike many unix shells currently available. after years of using bash/zsh, i still don't know all the quoting/expansion rules. not to mention that the man pages for each is massive.

"text is the only datatype". having only one datatype simplifies the shell language and encourages the use of other command line programs. arrays are represented by splitting on the null character and booleans are represented with an empty/non-empty string. mathematical operations should be done through a program suited for math.

"executables extend functionality". the list of builtins is fixed and there is no support for aliases, functions, or plugins. this implies that by improving your ax shell experience, you improve the experience of every other unix shell.

anyways, let's continue with the specification. i'm assuming previous knowledge with an existing unix shell.

basics

ax shares many core traits with other unix shells. here is an example of commands, comments, builtins, quoting, and pipes:

a few things to note from the above example:

nulls

one can easily join arguments together with the "?" syntax. by default, the "?" syntax joins arguments with the null character between each one, but "?" also supports joining arguments with any string:

"?" defaults to splitting with the null character because of a unique property the null character has on unix systems. null is the only character that unix systems don't allow in environment variables, filenames, and command arguments. but the null character can of course be part of stdin and stdout.

ax has a few different syntaxes for converting the stdout of a command to program arguments. the null character plays a key role in each one:

here is another way to think about the capture syntaxes when you are trying to decide which one to use:

strings

briefly mentioned earlier, "" or '' can be used to include text in a single argument. both "" and '' in ax behave in the same way as '' in bash. that is, there is no shell expansion or even escape codes supported between the quotes.

use the "~" syntax in ax to create a string that allows any text besides a certain delimiter you specify within it. the "~" syntax is similar to heredocs in bash. example:

as shown in the example above, the text after the first "~" and before the whitespace character is the delimiter that is also used to end the string. the end delimiter must be the same as the start delimiter, but with a whitespace character before it and a "~" after.

use the grave "`" to escape a single character. here are some examples with escaping characters:

vars

in ax, a command prefixed with "$" is actually a local variable. commands prefixed with "%" are environment variables. variable commands ignore stdin. variables commands with no arguments simply return their value, with arguments their value is set with null in between each argument and printed to stdout. here are some examples:

environment variables in the ax shell may contain the null character, but subprocesses will only get the text before the null character as a value. local and environment variables can be deleted by setting their value to the empty string:

builtins

builtins are prefixed with a ":". each builtin has special properties unique to that builtin. starting with ":cd" and ":exit":

ax has a few builtins that work with pipes, namely ":err", ":ret", and ":nil":

and finally, there are a few control builtins: ":fork", ":loop", and ":if. these builtins have a special property of being able to conditionally parse captures:

reference

here are all the special characters in the ax shell:

here are all the builtins:

conclusion

alright, i need to get on with my life again. i spent most of my friday and saturday working on this document. i'll probably come back to this in another month for v0.2.

some todos for v0.2: