rwsh

rwsh is a shell for Unix-like systems.

Documentation can be found in the docs directory. As it is still very much of
a proof-of-concept, there is no install or configure script.

It is not intended to be compatible with existing shells, or even to keep their
basic semantics. So please read at least the "introduction and
philosophy" document before assuming that you know what a command will do. For
example, rm without arguments may delete files (personally, I use rm without
arguments more often than with them).

Several changes are coming shortly, which may easily break scripts designed for
this version of the shell, including the following.
* .while will respond to the .retest_condition exception by testing the
condition, and ending the loop if it fails, but (unlike .continue)
continuing with the following statement if it succeeds.
* Functions will be able to take more than one argfunction with string
arguments being associated with each argfunction. For instance this
will permit .scope to take several prototypes with an argfunction for
each prototype, and will run the argfunction for which its arguments
match the corresponding prototype.
* "Soons" will be replaced with "Earlies". The syntax will not
(necessarily) change, but the meaning will. Rather than & meaning to
evaluate the first time a containing statement is evaluated and && meaning
to evaluate the second time a containing statement is evaluated, & will
mean to evaluate at the beginning of the innermost block, and && will
mean to evaluate at the beginning of the second most inner block. The
result will be that wrapping a set of statements in a .scope or
.collect_errors_* will not require changing the number of ampersands,
and that the statement ".set FOO &FOO" will have the effect of
restoring the value that $FOO had at the beginning of the block.
* Global variables will be replaced by a heirarchical set of scopes.
Functions will be declared to place their variables as a child of the
current scope (leaving none of the current variables immediately
accessible and combining all of its variables into a single value for
the current scope), or within the current scope (making all of the
current variables available and making the function's variables part of
the same map), or to attempt to do one of those two in the parent
scope. If there is no parent scope then a .no_more_turtles exception
will be thrown.
* Another use of the multiple argfunctions per statement will be the
.select_all and .select_last builtins. They will run each of their
argument functions in parallel, rotating between them when they input
or output or request to cooperate with peers. .select_all will run
until all argument functions complete, while .select_last will run
until the last argument function specified completes, sending a sigpipe
to any other argfunctions currently running.
* Variables and functions will likely share the same namespace, and using
a function as if it was a variable will be equivalent to calling it
without arguments. Running .set on such a function will call it with
the arguments, but will throw an exception if it terminates without
having the effect of setting the specified value (or throwing an
exception of its own).
* Redirections will be handled by internal functions, so that the effect
of >foo, or the configuration.
* When handling a set of arguments as a whole, rather than as a set of
words, any excess space that was included when specifying them will be
included.
* .for and .for_each_line will merge taking a separator and prototype(s)
as an argument and receiving the list to be iterated through on stdin.
Similarly, .scope and .reinterpret will take a separator with which to
split stdin, and then apply the prototype (each of which will no longer
need to be a single argument).
* .stepwise will step through the argument specifications as well as
through the statements of a function, permitting one, for example, to
identify the arguments that make use of a particular variable.
* Exception call stacks will include all of the arguments for each
function at each level of the call stack rather than just the
executable names.
* .run_logic will be replaced by a system that treats .shell as a service
which includes the request for user input, and which restarts after
each command. As with .function_not_found, a missing implementation
will be replaced with a simple implementation.
* a "/" will be used to define a heirarchy amongst executables and
variables. $foo/bar cannot be defined without defining $foo, and it
will return the portion of $foo that immediately follows "bar=".
Running "foo bar" will run the function that was named "foo/bar".
* Currently, $foo$3 returns the third word of the variable foo. This will
be replaced with a system of filters, which can be used to select
members of a structure without being limited to whitespace-delimited
structures, as well as being able to optionally handle variables that
are not defined.
* There will be "default redirections", so that interactive commands will
not necessarily have either their input or output connected to the
terminal. The builtin .is_default_input should be used to determine
whether a command is receiving its input effectively from the user, and
.is_default_output should be used to determine whether output is
intended to be printed on the terminal.
Other large changes are likely. To illustrate, before version 0.3, ERRNO was a
special variable, that would prevent the execution of control flow statements
such as .if and .while. Experience working with this setup convinced me that
the problem I was aiming at was worth taking on, but that my first solution was
actually an enormous pain most of the times it came up. I could very easily
come to the same conclusion about some other feature that I have already
implemented or will soon implement.