Inferno Shell

Last feature is most interesting. For example, standard command to compare two files cmp with help of this feature can compare output of two other commands instead of files: cmp <{ ls /dir1 } <{ ls /dir2 }.

Inferno uses unusual way to implement process’s exit status. In traditional OSes any process return integer when exits: 0 if everything is ok, and non-zero if error happened. In Inferno any process either just exits or raises unhandled exception, which value is a string with error description.

There is an agreement by which error description should begin with the "fail:" if this error is just exit status - i.e. the application doesn’t crashed, but simply wants to return error to the process who started this application (usually the shell). If error description won’t begin with "fail:", then after application exit it’s process will be kept in memory (in "broken" state), to make possible investigating crash reason using debugging tools (same as core dumps in *nix, but instead of saving them to disk they are kept in memory).

So, after command exits it "exit status" (exception text) will be available in environment variable $status (with prefix "fail:" removed; if there was nothing after "fail:" in exception text then $status will be set to "failed").

String is either a word without spaces and some special symbols, or any symbols in single quotes. Only symbol which can be escaped in such a string - single quote itself, and it’s escaped by doubling it:

There is no \n, \t, variable interpolation etc. in strings. If you need to add newline symbol inside a string - either just add it as is (by pressing Enter) or concatenate string with variable which contain this symbol. Inferno have app unicode(1) which can output any symbol by it’s code, so we can use it when need some special symbol in string (statement "{command} will be described later, but for now you can think it’s same as `command` in bash):

Double quotes doesn’t used for strings (btw, paired double quotes in inferno shell doesn’t used at all).

Command blocks are surrounded by braces, and such blocks processed by shell simple as single string (which include surrounding braces).

Only difference from usual strings in single quotes is: sh will check syntax in command blocks and slightly reformat it.

Lists of strings is just 0 or more strings separated by spaces. They can be surrounded by parens, but in most cases this is optional.

Any shell command is just list of strings, where first string in list is command name or command block, and all other strings are their params.

Operator ^ used to concatenate lists of strings. It can be applied to two lists with same amount of items (items will be concatenated by pair), or one of lists must contain just one item (which will be concatenated with every item of other list). As a special case, if both lists contain only one item - get the usual concatenation of two strings.

Usually one shell command must fit in single line - there is no special symbol to define "command continuation on next line". But it’s ease to have multiline command - just open on previous line string (with single quote) or command block (with open brace) or list of strings (with open paren), or end previous line with list concatenation operator.

Environment variables in OS Inferno implemented different to traditional OSes. Instead of adding new POSIX API to work with environment variables and providing them to every process using scaring things like int execvpe(const char *file, char *const argv[], char *const envp[]); in Inferno they are just files in /env directory. It gives some interesting features, such as the application can provide access to its environment variables to other applications on the network - just export (using listen(1) and export(4)) it’s /env.

It’s possible to create/delete/modify environment variables by creating, removing and changing files in /env. But you should take in account shell is keeping in memory copy of all environment variables, thus changes you’ll do using files in /env will be seen by apps you start after that, but not by current shell. When you modify environment variables in shell (using operator =) files in /env will be updated too.

In shell, names of variables may contain any symbols, including ones which not allowed in file names (like ., .. and including /). Variables with such names will be available only in current shell, but started apps won’t see them.

Another important difference - all variables contain only lists of strings. You can’t set variable to string - it’s always will be list of single string.

To delete variable set it to empty list (either explicitly with a=() or just with a=).

As you see, output of $var and $"var doesn’t differ, because echo output it’s params using single space as separator, and $" concatenate list items in same way. But first echo command received two params while last one received only one param.

Always where you implicitly concatenate value of variable with anything shell will inject explicit operator ^ (which, as you remember, work with lists, not strings). It is convenient, although while you not get used to it may be surprising:

Assigning to list of variables works too. If right side of assignment contain more items than variables in left side - last variable will receive tail of list, while all previous variables will contain lists with only one item.

List of all params for script or code block always available in variable $*, and each single param available in $1, $2, ….

Every command block define new local scope. You can set values to variables using operators = and :=. First will change value of existing variable or create new variable in current scope. Second always create new variable, hiding previous value of same-named variable (if any) until end of current block.

Name of variable is just a string after symbol $. And it can be anything which result in a string - like string in single quotes or another variable.

As I mentioned, any shell command is simply a list of strings, where the first string is the command name and the rest strings are it parameters. A command block is simply a string, and you can save it in a variable. And any command block receives parameters in $*, $1, etc.

Moreover, we can even do function curring just like in functional programming. :)

Another example - we can use command block params to get list item by it’s number:

I havn’t tried to implement full-featured and easy to use if, I wanted to implement for and thus implemented minimalistic if because it was needed for for (loop must stop at some point, and it’s hard to do this without conditional operator).