---
title: Philosophy (0.80)
---

# Nushell design philosophy

## Core philosophy

Nushell is "A shell-first scripting language for working with structured data flowing through pipelines".

Designs should work towards serving this goal. Those that don't should be removed or moved to optional add-ons.

## Core design

### Shell-first

Nushell should work to serve its role as a shell and a language with a focus on shells. Shell types of activities include, but aren't limited to:

- Running commands
- Redirecting stdout/stdin/stderr
- Unix-only: Properly handling signals
  - Ctrl-C
  - Ctrl-D
  - and others
- Support for background tasks
  - In Unix, this may mean Ctrl-Z and traditional background/foregrounding of tasks or a more modern approach

In cases where the user would reasonably have an expectation of the functionality of the shell, we should make every effort to include. If a feature would be a reasonable expectation (say ctrl-z on Unix), then we should have OS-specific functionality for that platform that meets that expectation.

### Scripting language

The intent of Nushell's design is to be a scripting language. Scripting can take many forms, from simple pipelines to large scripts. Nushell should handle these with ease by meeting reasonable expectations in terms of:

- Modularity
- Readability
- Programming language features and convenience

### Structured data

In Nushell, all data is "structured". For Nushell, this means that values can take shapes beyond just a simple string.

Values in Nushell can be records, lists, tables, binary data, and more. Being able to convert into structured data and work with structured data is fundamental to Nushell.

### Pipelines

Nushell takes the Unix philosophy of pipelines to heart. Commands should be built with the intent of composition. Nushell enables composition via the use of pipes (`|`), just like Unix pipelines.

Composing commands, both built-in and user-defined, is a core piece of Nushell. The design of Nushell and its standard library must support both easily composing commands as well as allowing the user to easily create compose-able commands.

### Command philosophy

Specifically, Nushell's philosophy about commands is represented by the following positions (these apply especially to the library of builtin commands distributed with nushell, but are also good guidance for your own commands and plugins):

1. There should be one -- and preferably only one -- obvious way to do it.
   You will probably recognize this from the "[Zen of Python](https://peps.python.org/pep-0020/)"!

2. The aim of our library of builtin commands is to provide a collection of simple and composable primitive commands, that covers essential shell programming needs and allows virtually anything to be built via composition and creation of custom user commands and plugins.
   That's as opposed to maintaining an extensive catalog of more specialized commands in the core nushell codebase: more specialized functionality should exist as community-contributed libraries (e.g. plugins/nushell libraries).

3. If something can be done conveniently by composition of simpler commands then we do not add flags and options to do the same thing.

4. The primary input to a command should generally be supplied as "input", not as a positional argument.
   This is what enables pipeline composition.

5. A given command, on a given input, should generally always produce the same type of output data structure; the presence/absence/value of arguments and flags shouldn't change the output type.

6. Commands should not consume their entire input streams unless that is explicitly part of the functionality of that command.

## Command signatures and their parts

### Signature

The signature of the command describes the following:

- The name of the command
- The usage information (documentation) for the command
- The name and type of:
  - Named parameters
  - Positional parameters
- The type of:
  - Input
  - Output

### When to use input