This project is currently in its early stages, though it already works well enough for contributors to dogfood it as their daily driver. Its design is subject to change as it matures.
Nu has a list of built-in commands (listed belowed). If a command is unknown, the command will shell-out and execute it (using cmd on Windows or bash on Linux and MacOS), correctly passing through stdin, stdout and stderr, so things like your daily git workflows and even `vim` will work just fine.
Nu draws heavy inspiration from projects like PowerShell. Rather than thinking of you filesystem and services as raw streams of text, Nu looks at each input as something with structure. When you list the contents of a directory, what you get back in a list of objects, where each object represents an item in that directory.
## Pipelines
Nu takes this a step further and builds heavily on the idea of _pipelines_. Just as the Unix philosophy, Nu allows commands to output from stdout and ready from stdin. Additionally, commands can output structured data (you can think of this as a kind of third stream). Commands that work in the pipeline fit into one of three categories
* Commands that produce a stream (eg, "ls")
* Commands that filter a stream (eg, "where size > 10")
* Commands that consumes the output of the pipeline (eg, "autoview")
```
/home/jonathan/Source/nushell(master)> ls | where "file type" == "Directory" | autoview
Because most of the time you'll want to see the output of a pipeline, `autoview` is assumed, so we could have also written the above:
```
/home/jonathan/Source/nushell(master)> ls | where "file type" == "Directory"
```
Being able to use the same commands and compose them differently is an important philosophy in Nu. For example, we could use the built-in `ps` command as well to get a list of the running processes, using the same `where` as above.
Nu can load file and URL contents as raw text or as structured data (if it recognizes the format). For example, you can load a .toml file as structured data and explore it:
```
/home/jonathan/Source/nushell(master)> open Cargo.toml
Finally, we can use commands outside of Nu once we have the data we want:
```
/home/jonathan/Source/nushell(master)> open Cargo.toml | get package.version | echo $it
0.1.2
```
Here we use the variable `$it` to refer to the value being piped to the external command.
## Navigation
By default, Nu opens up into your filesystem and the current working directory. One way to think of this is a pair: the current object and the current path in the object. The filesystem is our first object, and the path is the cwd.
| object | path |
| ------ | ---- |
| Filesystem | /home/jonathan/Source/nushell |
Using the `cd` command allows you to change the path from the current path to a new path, just as you might expect. Using 'ls' allows you to view the contents of the filesystem at the current path (or at the path of your choosing).
In addition to `cd` and `ls`, we can `enter` an object. Entering an object makes it the current object to navigate (similar to the concept of mounting a filesystem in Unix systems).
```
/home/jonathan/Source/nushell(master)> enter Cargo.toml
object/>
```
As we enter, we create a stack of objects we're navigating:
| object | path |
| ------ | ---- |
| Filesystem | /home/jonathan/Source/nushell |
| object (from Cargo.toml) | / |
Commands `cd` and `ls` now work on the object being navigated.
The `exit` command will pop the stack and get us back to a previous object we were navigating.
# Goals
Nu adheres closely to a set of goals that make up its design philosophy. As features are added, they are checked against these goals.
* First and foremost, Nu is cross-platform. Commands and techniques should carry between platforms and offer first-class consistent support for Windows, macOS, and Linux.
* Nu ensures direct compatibility with existing platform-specific executables that make up people's workflows.
* Nu's workflow and tools should have the usability in day-to-day experience of using a shell in 2019 (and beyond).
* Nu views data as both structured and unstructured. It is an object shell like PowerShell.
These goals are all critical, project-defining priorities. Priority #1 is "direct compatibility" because any new shell absolutely needs a way to use existing executables in a direct and natural way.