When expanding arguments, if an argument evaluates to an empty argument,
simply ignore the argument as if it didn't exist.

This will move the readln logic from `shell::binary` into
`shell::binary::readln`.

This will eliminate some redundancy caused by manually handling forking
logic in two different areas: command expansions, and function prompts.
This replacement takes a closure which provides access to the inner
child's Shell structure, and automatically handles setting up pipes
and returning the standard output as a String.

As an added bonus, this also eliminates the need to copy the PROMPT
function before executing it.

Although builtin commands like read aren't working yet.

Bump bitflags to 1.0

Now that we have process expansion support implemented, this isn't needed anymore.

Process expansions are now being performed as an internal fork within the shell.
Previously, this was done by passing executing a new Ion binary with a given command.
Work is not 100% complete, however. There's some TODOs that label what's not done yet.

- Quoting rules for process expansions has been fixed
- However, we should investigate a performance optimization to eliminate heap allocations there.
- At the moment, as with background shells, stdin within the child of the fork is disabled. Fix this.
- And, we need to remove our pre-process expansion expansions.

`which` builtin

Closes #560

- !! expands to the last command
- !$ expands to the last command's arguments

Severely trims down on LOC for performing assignments.

Rather than returning raw fds, we will return Files

Christopher Vittal authored 7 years ago and Michael Aaron Murphy committed 7 years ago

Add multiple redirections, that is, support for things like:

```
cmd <file1 <file2 ^>> err-log > output | cmd2
```
In current ion this doesn't work.

This change at current would be breaking as the statement:
```
tr 'x' 'y' | tr 'y' 'z' < file > file2
```
redirects `file` to the first `tr` command. With this change, we would redirect it to the second.

## Overview
We treat a multiple redirection as it's own job. The only difference between these jobs and normal jobs is that they only read from their source(s) and then write to their sink(s).

### Parsing
Alter `Pipline` contain a vector of `PipeItem`s. A `PipeItem` consists of a `Job`, a `Vec<Redirection>` and a `Vec<Input>`. The above statement would be parsed into two items, `cmd` together with `[file1, file2]` as input and `[err-log, output]` as outputs, and `cmd2` with no `Input`s or `Redirection`s

### Command Generation and Redirection Setup
Added two two new variants of `RefinedJob`, `Cat` and `Tee`, `Cat` for concatenating multiple inputs, `Tee` for splitting multiple outputs. Alter the `generate_commands` function to return a `Vec<(RefinedJob, JobKind, Vec<Redirection>, Vec<Input>)>`, then condense `redirect_input` and `redirect_output` into one function that takes ownership and returns a new `Vec<(RefinedJob, JobKind)>`. It is here that we create the `Tee` and `Cat` jobs that we need and put them in the right spot in the pipeline.

### Execution
Add `exec_multi_in` and `exec_multi_out` to handle the multiple redirections. These are fairly straightforward, they just read their sources and write to their sinks. I didn't add any extra paths to `exec_job` as the new `RefinedJob` kinds are always part of a pipeline.

Closes #558

Closes #547

This will remove all dependency upon the nix crate, as we will be
using `libc` directly for the `waitpid` functionality on *nix
systems. This should also make it easier to integrate with Redox.

Rather than using AtomicUsize and AtomicBool fields within
our ForegroundSignals structure, I'm switching this over
to using AtomicU32 and AtomicU8 values instead.

Closes #557

Closes #554

With this change, the following is now valid syntax:

let array = [
    one two
    three # a comment
    four # another comment
]

echo $join(array, "\n")