A new type of shell

Overview

README

Crates.io Build Status Discord The Changelog #363 @nu_shell GitHub commit activity GitHub contributors

Nushell

A new type of shell.

Example of nushell

Status

This project has reached a minimum-viable product level of quality. While contributors dogfood it as their daily driver, it may be unstable for some commands. Future releases will work to fill out missing features and improve stability. Its design is also subject to change as it matures.

Nu comes with a set of built-in commands (listed below). 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.

Learning more

There are a few good resources to learn about Nu. There is a book about Nu that is currently in progress. The book focuses on using Nu and its core concepts.

If you're a developer who would like to contribute to Nu, we're also working on a book for developers to help you get started. There are also good first issues to help you dive in.

We also have an active Discord and Twitter if you'd like to come and chat with us.

You can also find information on more specific topics in our cookbook.

Try it in Gitpod.

Open in Gitpod

Installation

Local

Up-to-date installation instructions can be found in the installation chapter of the book. Windows users: please note that Nu works on Windows 10 and does not currently have Windows 7/8.1 support.

To build Nu, you will need to use the latest stable (1.47 or later) version of the compiler.

Required dependencies:

  • pkg-config and libssl (only needed on Linux)
    • On Debian/Ubuntu: apt install pkg-config libssl-dev

Optional dependencies:

  • To use Nu with all possible optional features enabled, you'll also need the following:
    • On Linux (on Debian/Ubuntu): apt install libxcb-composite0-dev libx11-dev

To install Nu via cargo (make sure you have installed rustup and the latest stable compiler via rustup install stable):

cargo install nu

You can also build Nu yourself with all the bells and whistles (be sure to have installed the dependencies for your platform), once you have checked out this repo with git:

cargo build --workspace --features=extra

Docker

Quickstart

Want to try Nu right away? Execute the following to get started.

docker run -it quay.io/nushell/nu:latest

Guide

If you want to pull a pre-built container, you can browse tags for the nushell organization on Quay.io. Pulling a container would come down to:

docker pull quay.io/nushell/nu
docker pull quay.io/nushell/nu-base

Both "nu-base" and "nu" provide the nu binary, however nu-base also includes the source code at /code in the container and all dependencies.

Optionally, you can also build the containers locally using the dockerfiles provided: To build the base image:

docker build -f docker/Dockerfile.nu-base -t nushell/nu-base .

And then to build the smaller container (using a Multistage build):

docker build -f docker/Dockerfile -t nushell/nu .

Either way, you can run either container as follows:

docker run -it nushell/nu-base
docker run -it nushell/nu
/> exit

The second container is a bit smaller if the size is important to you.

Packaging status

Packaging status

Fedora

COPR repo: sudo dnf copr enable atim/nushell -y && sudo dnf install nushell -y

Philosophy

Nu draws inspiration from projects like PowerShell, functional programming languages, and modern CLI tools. Rather than thinking of files and services as raw streams of text, Nu looks at each input as something with structure. For example, when you list the contents of a directory, what you get back is a table of rows, where each row represents an item in that directory. These values can be piped through a series of steps, in a series of commands called a 'pipeline'.

Pipelines

In Unix, it's common to pipe between commands to split up a sophisticated command over multiple steps. 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 read from stdin. Additionally, commands can output structured data (you can think of this as a third kind of 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 type == "Dir")
  • Commands that consume the output of the pipeline (eg, autoview)

Commands are separated by the pipe symbol (|) to denote a pipeline flowing left to right.

> ls | where type == "Dir" | autoview
───┬────────┬──────┬───────┬──────────────
 # │ name   │ type │ size  │ modified
───┼────────┼──────┼───────┼──────────────
 0 │ assets │ Dir  │ 128 B │ 5 months ago
 1 │ crates │ Dir  │ 704 B │ 50 mins ago
 2 │ debian │ Dir  │ 352 B │ 5 months ago
 3 │ docker │ Dir  │ 288 B │ 3 months ago
 4 │ docs   │ Dir  │ 192 B │ 50 mins ago
 5 │ images │ Dir  │ 160 B │ 5 months ago
 6 │ src    │ Dir  │ 128 B │ 1 day ago
 7 │ target │ Dir  │ 160 B │ 5 days ago
 8 │ tests  │ Dir  │ 192 B │ 3 months ago
───┴────────┴──────┴───────┴──────────────

Because most of the time you'll want to see the output of a pipeline, autoview is assumed. We could have also written the above:

> ls | where type == Dir

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.

> ps | where cpu > 0
───┬────────┬───────────────────┬──────────┬─────────┬──────────┬──────────
 # │ pid    │ name              │ status   │ cpu     │ mem      │ virtual
───┼────────┼───────────────────┼──────────┼─────────┼──────────┼──────────
 0 │    435 │ irq/142-SYNA327   │ Sleeping │  7.5699 │      0 B │      0 B
 1 │   1609 │ pulseaudio        │ Sleeping │  6.5605 │  10.6 MB │   2.3 GB
 2 │   1625 │ gnome-shell       │ Sleeping │  6.5684 │ 639.6 MB │   7.3 GB
 3 │   2202 │ Web Content       │ Sleeping │  6.8157 │ 320.8 MB │   3.0 GB
 4 │ 328788 │ nu_plugin_core_ps │ Sleeping │ 92.5750 │   5.9 MB │ 633.2 MB
───┴────────┴───────────────────┴──────────┴─────────┴──────────┴──────────

Opening files

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:

> open Cargo.toml
────────────────────┬───────────────────────────
 bin                │ [table 18 rows]
 build-dependencies │ [row serde toml]
 dependencies       │ [row 29 columns]
 dev-dependencies   │ [row nu-test-support]
 features           │ [row 19 columns]
 package            │ [row 12 columns]
 workspace          │ [row members]
────────────────────┴───────────────────────────

We can pipeline this into a command that gets the contents of one of the columns:

> open Cargo.toml | get package
───────────────┬────────────────────────────────────
 authors       │ [table 1 rows]
 default-run   │ nu
 description   │ A new type of shell
 documentation │ https://www.nushell.sh/book/
 edition       │ 2018
 exclude       │ [table 1 rows]
 homepage      │ https://www.nushell.sh
 license       │ MIT
 name          │ nu
 readme        │ README.md
 repository    │ https://github.com/nushell/nushell
 version       │ 0.21.0
───────────────┴────────────────────────────────────

Finally, we can use commands outside of Nu once we have the data we want:

> open Cargo.toml | get package.version
0.21.0

Here we use the variable $it to refer to the value being piped to the external command.

Configuration

Nu has early support for configuring the shell. You can refer to the book for a list of all supported variables.

To set one of these variables, you can use config set. For example:

> config set line_editor.edit_mode "vi"
> config set path $nu.path

Shells

Nu will work inside of a single directory and allow you to navigate around your filesystem by default. Nu also offers a way of adding additional working directories that you can jump between, allowing you to work in multiple directories at the same time.

To do so, use the enter command, which will allow you create a new "shell" and enter it at the specified path. You can toggle between this new shell and the original shell with the p (for previous) and n (for next), allowing you to navigate around a ring buffer of shells. Once you're done with a shell, you can exit it and remove it from the ring buffer.

Finally, to get a list of all the current shells, you can use the shells command.

Plugins

Nu supports plugins that offer additional functionality to the shell and follow the same structured data model that built-in commands use. This allows you to extend nu for your needs.

There are a few examples in the plugins directory.

Plugins are binaries that are available in your path and follow a nu_plugin_* naming convention. These binaries interact with nu via a simple JSON-RPC protocol where the command identifies itself and passes along its configuration, which then makes it available for use. If the plugin is a filter, data streams to it one element at a time, and it can stream data back in return via stdin/stdout. If the plugin is a sink, it is given the full vector of final data and is given free reign over stdin/stdout to use as it pleases.

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 a structured shell like PowerShell.

  • Finally, Nu views data functionally. Rather than using mutation, pipelines act as a means to load, change, and save data without mutable state.

Commands

You can find a list of Nu commands, complete with documentation, in quick command references.

Progress

Nu is in heavy development, and will naturally change as it matures and people use it. The chart below isn't meant to be exhaustive, but rather helps give an idea for some of the areas of development and their relative completion:

Features Not started Prototype MVP Preview Mature Notes
Aliases X Initial implementation but lacks necessary features
Notebook X Initial jupyter support, but it loses state and lacks features
File ops X cp, mv, rm, mkdir have some support, but lacking others
Environment X Temporary environment, but no session-wide env variables
Shells X Basic value and file shells, but no opt-in/opt-out for commands
Protocol X Streaming protocol is serviceable
Plugins X Plugins work on one row at a time, lack batching and expression eval
Errors X Error reporting works, but could use usability polish
Documentation X Book and related are barebones and lack task-based lessons
Paging X Textview has paging, but we'd like paging for tables
Functions X No functions, yet, only aliases
Variables X Nu doesn't yet support variables
Completions X Completions are currently barebones, at best
Type-checking X Commands check basic types, but input/output isn't checked

Current Roadmap

We've added a Roadmap Board to help collaboratively capture the direction we're going for the current release as well as capture some important issues we'd like to see in Nushell. You can find the Roadmap here.

Contributing

See Contributing for details.

Thanks to all the people who already contributed!

License

The project is made available under the MIT license. See the LICENSE file for more information.

Comments
  • [MVP][WIP] `less` like pager

    [MVP][WIP] `less` like pager

    Run it as explore.

    example

    ls | explore
    

    Configuration points in config.nu file.

      # A 'explore' utility config
       explore_config: {
         highlight: { bg: 'yellow', fg: 'black' }
         status_bar: { bg: '#C4C9C6', fg: '#1D1F21' }
         command_bar: { fg: '#C4C9C6' }
         split_line: '#404040'
         cursor: true
         # selected_column: 'blue'
         # selected_row: { fg: 'yellow', bg: '#C1C2A3' }
         # selected_cell: { fg: 'white', bg: '#777777' }
         # line_shift: false,
         # line_index: false,
         # line_head_top: false,
         # line_head_bottom: false,
       }
    

    You can start without a pipeline and type explore and it'll give you a few tips. image

    If you type :help you an see the help screen with some information on what tui keybindings are available. image

    From the :help screen you can now hit i and that puts you in cursor aka inspection mode and you can move the cursor left right up down and it you put it on an area such as [table 5 rows] and hit the enter key, you'll see something like this, which shows all the : commands. If you hit esc it will take you to the previous screen. image

    If you then type :try you'll get this type of window where you can type in the top portion and see results in the bottom. image

    The :nu command is interesting because you can type pipelines like :nu ls | sort-by type size or another pipeline of your choosing such as :nu sys and that will show the table that looks like this, which we're calling "table mode". image

    If you hit the t key it will now transpose the view to look like this. image

    In table mode or transposed table mode you can use the i key to inspect any collapsed field like {record 8 fields}, [table 16 rows], [list x], etc.

    One of the original benefits was that when you're in a view that has a lot of columns, explore gives you the ability to scroll left, right, up, and down.

    explore is also smart enough to know when you're in table mode versus preview mode. If you do open Cargo.toml | explore you get this. image

    If you type open --raw Cargo.toml | explore you get this where you can scroll left, right, up, down. This is called preview mode. image

    When you're in table mode, you can also type :preview. So, with open --raw Cargo.toml | explore, if you type :preview, it will look like this. image

    opened by zhiburt 87
  • WIP/ Checkout to new `tabled`

    WIP/ Checkout to new `tabled`

    Hello,

    This PR must make tables faster while not break anything.

    I was pointing out a few times that there were areas where tabled clearly could do a better job. I did have some progress, so I wanted to show it to you so maybe you could make tests.

    for example running 1..100000 (#5972) gives me 262

    cc: @fdncred

    tabled 
    opened by zhiburt 49
  • nu-0.59.1 build failure

    nu-0.59.1 build failure

    Describe the bug

    nu-0.59.1 from commit 9db356e174288e74f7b5374d679b72907731eb70 fails to build on NetBSD.

    First attempt to build fails since NetBSD libc doesn't support trash-support

    I've disabled this feature at build time and have the following features enabled, "plugin", "which", "zip-support".

    But, I'm hitting the following build error,

    Compiling nu-command v0.59.1 (/usr/pkgsrc/wip/nushell/work/nushell-9db356e174288e74f7b5374d679b72907731eb70/crates/nu-command)
    error[E0425]: cannot find function `collect_proc` in crate `nu_system`
      --> crates/nu-command/src/system/ps.rs:74:28
       |
    74 |     for proc in nu_system::collect_proc(Duration::from_millis(100), false) {
       |                            ^^^^^^^^^^^^ not found in `nu_system`
    
    For more information about this error, try `rustc --explain E0425`.
    error: could not compile `nu-command` due to previous error
    *** Error code 101
    
    Stop.
    

    How to reproduce

    Build nu from git-HEAD

    Expected behavior

    Build finishes successfully.

    Screenshots

    No response

    Configuration

    No response

    Additional context

    OS: NetBSD-current (9.99.94) Rust: 1.59.0

    help wanted platform-specific investigate 
    opened by 0323pin 47
  • Table paging (Draft PR)

    Table paging (Draft PR)

    This adds paging to the table output.

    This does change a few methods to return String's instead of printing to screen (this may want to be reworked to be async?), so it's a little invasive.

    still a couple of warnings, and possible errors to be handled correctly. I will look at these soon.

    Cheers

    opened by rezural 47
  • Declare input and output types of commands

    Declare input and output types of commands

    This PR adds input_output_types: Vec<(Type, Type)> to the command Signature struct. This is a collection of all the different input-output type signature variants.

    The declared input and output types (shapes) are enforced by the test suite: they are checked when executing every example.

    There are two main commits:

    • https://github.com/nushell/nushell/pull/6796/commits/3b5a6cbbbf4821b0fd7051eb30c2b195d672e477 sets things up so that we can declare input-output type signatures and verifies them in the tests of examples

    • https://github.com/nushell/nushell/pull/6796/commits/f47ba5240881ec0387f596b8d160f713fe2da24d is a big commit that adds signatures to all commands that have automatically-tested examples (and adds/changes command examples along the way so that they cause the tests to pass)

    The bottom line is that once this merges, we'll have the following rule:

    • If a command has examples, every example must match one of the input-output type signatures.
    • If the command has declared input-output type signatures, then every signature variant must have at least one example matching that signature.

    Subsequently, we can add this information to the help commands and $nu.scope.commands tables, so that users can query nushell commands by their input and output types.

    We can also use this to add signatures to the text help pages, peraps like https://github.com/nushell/nushell/issues/6754.

    Being able to query commands by type will also provide a way to study the way that builtin commands are named, to check that we're keeping things reasonably consistent (e.g. to help with things like https://github.com/nushell/nushell/issues/6744).

    image
    • [x] Fail the test if any example did not match any input-output type pair
    • [x] Fail the test if any input-output type pair did not match any example
    • [ ] Check example does appear to be testing the right command
    • [ ] Query: commands accepting table but not record
    opened by dandavison 39
  • Support for Anaconda `conda` environments from nushell

    Support for Anaconda `conda` environments from nushell

    Is your feature request related to a problem? Please describe. I love nushell, but it seems that nushell is not currently compatible with the python Anaconda distribution. I was not sure where to direct this request, but I thought I would start with the nushell folks. So Anaconda is a python distribution for scientific computing. Users can create conda virtual environments and then activate those environments using the command conda activate <environment_name>.

    When I tried to use conda activate myenv I got a message:

    CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
    To initialize your shell, run
    
        $ conda init <SHELL_NAME>
    
    Currently supported shells are:
      - bash
      - fish
      - tcsh
      - xonsh
      - zsh
      - powershell
    
    See 'conda init --help' for more information and options.
    
    

    Seems like this might be an upstream Anaconda issue, but I though I might check with the nushell team on whether there have been discussions about this.

    Describe the solution you'd like I would like to be able to activate Anaconda environments using nushell.

    Describe alternatives you've considered The alternative is to stay with zsh for anything involving Anaconda or python.

    Additional context Add any other context or screenshots about the feature request here. No other info. Thanks for your consideration. I will post to the conda maintainers as well.

    opened by 00krishna 39
  • color_config now accepts closures as color values

    color_config now accepts closures as color values

    Description

    Closes #6909. You can now add closures to your color_config themes. Whenever a value would be printed with table, the closure is run with the value piped-in. The closure must return either a {fg,bg,attr} record or a color name ('light_red' etc.). This returned style is used to colour the value.

    This is entirely backwards-compatible with existing config.nu files.

    Example code excerpt:

    let my_theme = {
        header: green_bold
        bool: { if $in { 'light_cyan' } else { 'light_red' } }
        int: purple_bold
        filesize: { |e| if $e == 0b { 'gray' } else if $e < 1mb { 'purple_bold' } else { 'cyan_bold' } }
        duration: purple_bold
        date: { (date now) - $in | if $in > 1wk { 'cyan_bold' } else if $in > 1day { 'green_bold' } else { 'yellow_bold' } }
        range: yellow_bold
        string: { if $in =~ '^#\w{6}$' { $in } else { 'white' } }
        nothing: white
    

    Example output with this in effect: 2022-11-16 12 47 23 AM - style_computer rs_-nushell-_VSCodium 2022-11-16 12 39 41 AM - style_computer rs_-nushell-_VSCodium 2022-11-15 09 21 54 PM - run_external rs_-nushell-_VSCodium

    Slightly important notes:

    • Some color_config names, namely "separator", "empty" and "hints", pipe in null instead of a value.
    • Currently, doing anything non-trivial inside a closure has an understandably big perf hit. I currently do not actually recommend something like string: { if $in =~ '^#\w{6}$' { $in } else { 'white' } } for serious work, mainly because of the abundance of string-type data in the world. Nevertheless, lesser-used types like "date" and "duration" work well with this.
    • I had to do some reorganisation in order to make it possible to call eval_block() that late in table rendering. I invented a new struct called "StyleComputer" which holds the engine_state and stack of the initial table command (implicit or explicit).
    • StyleComputer has a compute() method which takes a color_config name and a nu value, and always returns the correct Style, so you don't have to worry about A) the color_config value was set at all, B) whether it was set to a closure or not, or C) which default style to use in those cases.
    • Currently, errors encountered during execution of the closures are thrown in the garbage. Any other ideas are welcome. (Nonetheless, errors result in a huge perf hit when they are encountered. I think what should be done is to assume something terrible happened to the user's config and invalidate the StyleComputer for that table run, thus causing subsequent output to just be Style::default().)
    • More thorough tests are forthcoming - ran into some difficulty using nu! to take an alternative config, and for some reason let-env config = statements don't seem to work inside nu! pipelines(???)
    • The default config.nu has not been updated to make use of this yet. Do tell if you think I should incorporate that into this.

    User-Facing Changes

    See above.

    Tests + Formatting

    Don't forget to add tests that cover your changes.

    Make sure you've run and fixed any issues with these commands:

    • cargo fmt --all -- --check to check standard code formatting (cargo fmt --all applies these changes)
    • cargo clippy --workspace --features=extra -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect to check that you're using the standard code style
    • cargo test --workspace --features=extra to check that all tests pass

    After Submitting

    If your PR had any user-facing changes, update the documentation after the PR is merged, if necessary. This will help us keep the docs up to date.

    opened by webbedspace 36
  • Optional chaining for cell paths (`?.`)

    Optional chaining for cell paths (`?.`)

    This PR adds the ability to use ?. in cell paths, somewhat like optional chaining in JS and C#'s null-conditional operator.

    This provides a succinct way for users to specify whether a failed cell path access should return a ShellError or Value::Nothing. It is not aiming for exact compatibility with JS and C#.

    Examples

    # fails because Value::Nothing has no data to access
    $nothing.foo
    # returns Value::Nothing because `?` was used
    $nothing?.foo
    
    # fails because `asdf` is not a column on the record
    {foo: 'bar'}.asdf
    # returns Value::Nothing because `?` was used
    {foo: 'bar'}?.asdf
    
    # fails because `asdf` is not a column on the nested record
    {foo: {bar: 'baz'} }.foo.asdf
    # returns Value::Nothing
    {foo: {bar: 'baz'} }.foo?.asdf
    
    # fails because there is no 10th row in the list
    [{foo: 'bar'}].10
    # returns Value::Nothing
    [{foo: 'bar'}]?.10
    
    # fails because there is no `foo` column in the 2nd row
    # BREAKING CHANGE - PREVIOUSLY THIS WOULD SUCCEED AS LONG AS 1+ ROW HAD A `foo` COLUMN
    [{foo: 'bar'} {}].foo
    
    # returns a `list<any>` with 2 values: "bar" and $nothing
    [{foo: 'bar'} {}]?.foo
    

    How does this relate to get and select?

    As always, any cell path access can be rewritten to use get (ex: $foo.a -> $foo | get a). The arguments given to get and select (ex: foo and bar in select foo bar) are actually cell paths.

    Before this PR, cell paths used by get and select were not allowed to start with a .; parsing get .a would fail. After this PR, a . before the first member is (optionally) allowed. All of the following are now valid:

    get a
    get .a
    get ?a
    get ?.a
    

    I think this makes sense; the user's intent is unambiguous in each case and it provides consistency whether using get or accessing a cell path without get.

    As part of this PR, the -i/--ignore-errors flag has been removed from get and select. Using ? in cell paths now offers more fine-grained control over error handling:

    # this fails because `b` is missing on the 2nd row (not new behaviour)
    [{a: 1, b: 2} {a: 3}] | select b
    
    # previously you had to use something like `default` to convert missing values to null
    [{a: 1, b: 2} {a: 3}] | default null b | select b
    
    # the old `-i` flag would return a single null value instead of a table with some null cells - usually not what you want!
    [{a: 1, b: 2} {a: 3}] | select -i b
    
    # now you can use `?`
    [{a: 1, b: 2} {a: 3}] | select ?b
    

    Future Work

    If this change lands, I should be able to follow it up with another PR that makes cell path access stream properly instead of collecting ListStreams.

    breaking-change 
    opened by rgwood 35
  • Grouped config commands better (closes #6911)

    Grouped config commands better (closes #6911)

    Description

    • Closes #6911. The new structure of the default config is this:
      ls: {
        use_ls_colors: true # use the LS_COLORS environment variable to colorize output
        clickable_links: true # enable or disable clickable links. Your terminal has to support links.
      }
      rm: {
        always_trash: true # always act as if -t was given. Can be overridden with -p
      }
      cd: {
        abbreviations: true # allows `cd s/o/f` to expand to `cd some/other/folder`
      }
      table: {
        mode: rounded # basic, compact, compact_double, light, thin, with_love, rounded, reinforced, heavy, none, other
        index_mode: always # "always" show indexes, "never" show indexes, "auto" = show indexes when a table has "index" column
        trim: {
          methodology: wrapping # wrapping or truncating
          wrapping_try_keep_words: true # A strategy used by the 'wrapping' methodology
          truncating_suffix: "..." # A suffix used by the 'truncating' methodology
        }
      }
      history: {
        max_size: 10000 # Session has to be reloaded for this to take effect
        sync_on_enter: true # Enable to share history between multiple sessions, else you have to close the session to write history to file
        file_format: "plaintext" # "sqlite" or "plaintext"
      }
      completions: {
        case_sensitive: false # set to true to enable case-sensitive completions
        quick: true  # set this to false to prevent auto-selecting completions when only one remains
        partial: true  # set this to false to prevent partial filling of the prompt
        algorithm: "prefix"  # prefix or fuzzy
        external: {
          enable: true # set to false to prevent nushell looking into $env.PATH to find more suggestions, `false` recommended for WSL users as this look up my be very slow
          max_results: 100 # setting it lower can improve completion performance at the cost of omitting some options
          completer: null # check 'carapace_completer' above as an example
        }
      }
      filesize: {
        metric: true # true => KB, MB, GB (ISO standard), false => KiB, MiB, GiB (Windows standard)
        format: "auto" # b, kb, kib, mb, mib, gb, gib, tb, tib, pb, pib, eb, eib, zb, zib, auto
      }
    

    All old options' positions continue to be read as usual, and there are currently no deprecation warnings given.

    • Changes the default always_trash option to true because I feel it's a safer default for basic usage. (negotiable)

    • Also tweaks the wording of rm's help in a few places.

    Tests + Formatting

    Make sure you've done the following, if applicable:

    • Add tests that cover your changes (either in the command examples, the crate/tests folder, or in the /tests folder)
      • Try to think about corner cases and various ways how your changes could break. Cover those in the tests

    Make sure you've run and fixed any issues with these commands:

    • cargo fmt --all -- --check to check standard code formatting (cargo fmt --all applies these changes)
    • cargo clippy --workspace --features=extra -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect to check that you're using the standard code style
    • cargo test --workspace --features=extra to check that all tests pass

    User-Facing Changes

    If you're making changes that will affect the user experience of Nushell (ex: adding/removing a command, changing an input/output type, adding a new flag):

    • Get another regular contributor to review the PR before merging
    • Make sure that there is an entry in the documentation (https://github.com/nushell/nushell.github.io) for the feature, and update it if necessary
    wait-until-after-nushell-release breaking-change 
    opened by webbedspace 35
  • Add decimals to int when using `into string --decimals`

    Add decimals to int when using `into string --decimals`

    Description

    This is a follow up to PR https://github.com/nushell/nushell/pull/6084. It was intended as a fix to https://github.com/nushell/nushell/issues/6078 but @merelymyself beat me to it.

    However, this PR adds the decimal digits in a way that they get also added when group_digits is set to true (see: https://github.com/nushell/nushell/issues/6078#issuecomment-1189636421).

    I also added tests for into string when converting int with --decimals.

    Tests

    Make sure you've done the following:

    • [x] Add tests that cover your changes, either in the command examples, the crate/tests folder, or in the /tests folder.
    • [x] Try to think about corner cases and various ways how your changes could break. Cover them with tests.
    • [ ] ~If adding tests is not possible, please document in the PR body a minimal example with steps on how to reproduce so one can verify your change works.~

    Make sure you've run and fixed any issues with these commands:

    • [x] cargo fmt --all -- --check to check standard code formatting (cargo fmt --all applies these changes)
    • [x] cargo clippy --workspace --features=extra -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect to check that you're using the standard code style
    • [x] cargo test --workspace --features=extra to check that all the tests pass
    opened by x3rAx 34
  • Documentation for Nu commands (NO programming experience needed)

    Documentation for Nu commands (NO programming experience needed)

    We need documentation for the following Nu internal commands in any speaking language of your choosing:

    If interest in working on a command, please read this first.

    Please note: These are Nu commands, they may be the same name as commands you might be familiar from other shells but their usage, flags, and functionality might be different. Please make sure you have latest Nu installation 0.4.0 (you can confirm this by running the version command under Nu).

    You can learn more about how a Nu command works by looking at the source code or from Nu itself running help command where command is the command you are interested in documenting.

    VERY IMPORTANT you try and experiment with the command using Nu to get ideas. (Updated 18th May, 2020)

    • [ ] autoview
    • [ ] binaryview
    • [ ] clear
    • [ ] cp
    • [ ] describe
    • [ ] drop
    • [ ] each
    • [ ] empty?
    • [ ] keep
    • [ ] keep-until
    • [ ] keep-while
    • [ ] kill
    • [ ] match
    • [ ] merge
    • [ ] mkdir
    • [ ] mv
    • [ ] n
    • [ ] p
    • [ ] parse
    • [ ] post
    • [ ] pwd
    • [ ] range
    • [ ] rm
    • [ ] shuffle
    • [ ] skip-until
    • [ ] split-by
    • [ ] table
    • [ ] textview
    • [ ] touch
    • [ ] tree
    • [ ] with-env
    help wanted good first issue documentation meta-issue 
    opened by andrasio 34
  • Pipes are not checking for errors before sending it ot the next one

    Pipes are not checking for errors before sending it ot the next one

    Describe the bug

    The bug is a bit hard to describe because I don't know what is failing exactly. but happens when using each and sending data from one pipe (that should fail) to another one pipe. Nushell throws the error at the end of all iterations instead of the first iteration.

    How to reproduce

    Here are some similar examples where it fails : 2. 1..100 | each { |i| sleep 400ms; echo $i; echo $i |save -f output.txt } 2. 1..100 | each { |i| sleep 400ms; print $i; echo $i |save -f output.txt } 3. 1..100 | each { |i| echo $i; echo $i |save -f output.txt }

    Expected behavior

    Nushell should throws an error after the first iteration.

    Screenshots

    nushell_error

    Configuration

    | key                | value                                |
    | ------------------ | ------------------------------------ |
    | version            | 0.73.0                               |
    | branch             |                                      |
    | commit_hash        |                                      |
    | build_os           | windows-x86_64                       |
    | build_target       | x86_64-pc-windows-msvc               |
    | rust_version       | rustc 1.66.0 (69f9c33d7 2022-12-12)  |
    | rust_channel       | stable-x86_64-pc-windows-msvc        |
    | cargo_version      | cargo 1.66.0 (d65d197ad 2022-11-15)  |
    | pkg_version        | 0.73.0                               |
    | build_time         | 2023-01-05 20:07:27 -05:00           |
    | build_rust_channel | release                              |
    | features           | database, default, trash, which, zip |
    | installed_plugins  |                                      |
    

    Additional context

    No response

    opened by Xoffio 2
  • Tab completion doesn't put ` tildes around filenames with parentheses

    Tab completion doesn't put ` tildes around filenames with parentheses

    Describe the bug

    Filenames with parentheses need ` tildes around them, but they aren't considered as such by tab completion (of files in the current directory).

    How to reproduce

    image As you can see, the filename above doesn't function despite being produced by tab completion.

    Expected behavior

    See above.

    Screenshots

    No response

    Configuration

    | key | value | | ------------------ | ---------------------------------------- | | version | 0.73.0 | | branch | main | | commit_hash | 1291b647aee4a566a69fc5786b5437cff3976d1b | | build_os | windows-x86_64 | | build_target | x86_64-pc-windows-msvc | | rust_version | rustc 1.65.0 (897e37553 2022-11-02) | | rust_channel | 1.65.0-x86_64-pc-windows-msvc | | cargo_version | cargo 1.65.0 (4bc8f24d3 2022-10-20) | | pkg_version | 0.73.0 | | build_time | 2022-12-21 16:52:27 +10:00 | | build_rust_channel | release | | features | database, default, trash, which, zip | | installed_plugins | |

    Additional context

    No response

    opened by webbedspace 0
  • change parse behaviour

    change parse behaviour

    Related problem

    At this moment parse quietly skips lines, that's does not match pattern:

    /> ^echo "one-1 two-2 three-3" | ^xargs -n1 | parse "{word}-{num}\n"
     #   word    num
    ─────────────────
     0   one     1
     1   two     2
     2   three   3
    
    /> ^echo "one-1 two-2 three+3" | ^xargs -n1 | parse "{word}-{num}\n"
     #   word   num
    ────────────────
     0   one    1
     1   two    2
    />
    

    ...and the same for regular expressions:

    /> ^echo "one two three" | ^xargs -n1 | parse -r "^([a-z]+)\n$"   
     #   Capture1
    ──────────────
     0   one
     1   two
     2   three
    
    /> ^echo "one two three=3" | ^xargs -n1 | parse -r "^([a-z]+)\n$" 
     #   Capture1
    ──────────────
     0   one
     1   two
    />
    

    While that behavior is rather consistent with shell constructs like awk '{ if ($0 ~ /^[a-z]+$/) { print $0 } }', it may be misleading for nushell users - especially with longer and more complicated cases, when skipping few lines may remain unnoticed.

    Describe the solution you'd like

    I wonder about following scenarios:

    1. [breaking change] - change parse to throw error, when line doesn't match provided pattern and provide additional option, for example lazy (as -l or --lazy) that restores old behavior for users, that are aware of that specific nuance

    2. [non-breaking change, but still may be misleading] add a warning message in such case and add lazy or quiet option for dismissing warnings. It may works if warning will be printed after a whole output, in other cases it may be overlooked

    3. [non-breaking change and still it will lead to confusion] - add a strict option, that requires all lines to match a pattern. In my humble opinion that one also may be troublesome, because we cannot rely on user to read all documentation, especially when whole environment is so usable and intuitive for most tasks...

    Describe alternatives you've considered

    No response

    Additional context and details

    No response

    enhancement 
    opened by aniou 2
  • Maybe syntax-highlight backslash escapes in double-quote strings, to convey the difference between them and single-quote strings

    Maybe syntax-highlight backslash escapes in double-quote strings, to convey the difference between them and single-quote strings

    Related problem

    I think it's currently not easy enough for new users to remember or discover the difference between the two quoting types, which can be painful given how vastly different in capabilities they are.

    Describe the solution you'd like

    image

    I notice that template strings have special internal syntax highlighting for their braces. This could be applied to double-quoted strings to convey that the escapes inside them are "active" (as compared to single-quote strings). I image the \n inside the second string could use the shape_string_interpolation colour (or more likely a different but similarly-named config colour).

    Describe alternatives you've considered

    No response

    Additional context and details

    No response

    enhancement 
    opened by webbedspace 0
  • Windows Terminal: Nushell crashes when running `open` to open a non-UTF-8 text file

    Windows Terminal: Nushell crashes when running `open` to open a non-UTF-8 text file

    Describe the bug

    When trying to open and display the contents of a text file encoded using ANSI instead of UTF-8, and when that file contains a non-UTF-8-compatible character, Nushell crashes.

    How to reproduce

    Unzip and open this file: ansi_text_file.zip

    〉open `01 BGM #01.m3u`
    DMG-ACUJ-JPN.gbs::GBS,0,BGM #01 - Yasuhisa Watanabe - Puchi Carat - Error: nu::shell::io_error (link)
    
      × I/O error
      help: Error { kind: InvalidData, message: "Windows stdio in console mode does not support writing non-UTF-8 byte sequences" }
    
    Error:
      × Error flushing stdio
    
    
    
    [process exited with code 1 (0x00000001)]
    

    Expected behavior

    etc.

    Screenshots

    No response

    Configuration

    | key | value | | ------------------ | ---------------------------------------- | | version | 0.73.0 | | branch | main | | commit_hash | 1291b647aee4a566a69fc5786b5437cff3976d1b | | build_os | windows-x86_64 | | build_target | x86_64-pc-windows-msvc | | rust_version | rustc 1.65.0 (897e37553 2022-11-02) | | rust_channel | 1.65.0-x86_64-pc-windows-msvc | | cargo_version | cargo 1.65.0 (4bc8f24d3 2022-10-20) | | pkg_version | 0.73.0 | | build_time | 2022-12-21 16:52:27 +10:00 | | build_rust_channel | release | | features | database, default, trash, which, zip | | installed_plugins | |

    Additional context

    No response

    opened by webbedspace 2
  • Refactor

    Refactor "to url" command in: "to url query"

    Description

    Refactor command: "to url" in: "to url query". Changed usage sentence. Closes: #7495

    User-Facing Changes

    Now we get a query string from a record or table by using command: "to url query".

    > help to url query
    Convert record or table into query string applying percent-encoding.
    
    Usage:
      > to url query
    
    Flags:
      -h, --help - Display the help message for this command
    
    Signatures:
      <record> | to url query -> <string>
      <table> | to url query -> <string>
    
    Examples:
      Outputs a query string representing the contents of this record
      > { mode:normal userid:31415 } | to url query
    
      Outputs a query string representing the contents of this 1-row table
      > [[foo bar]; ["1" "2"]] | to url query
    
      Outputs a query string representing the contents of this record
      > {a:"AT&T", b: "AT T"} | to url query
    

    Tests + Formatting

    Added this test:

    Example {
        description: "Outputs a query string representing the contents of this record",
        example: r#"{a:"AT&T", b: "AT T"} | to url query"#,
        result: Some(Value::test_string("a=AT%26T&b=AT+T")),
    },
    

    to ensure percent-encoding.

    After Submitting

    If PR is accepted I'll open another PR on documentation to notify changes on this.

    opened by VincenzoCarlino 7
Releases(0.73.0)
Owner
Nushell Project
Nushell Project
A procedural macro that copy-pastes match arms for new type variant enums.

All the same! If you ever had code that looks like this: use std::io; use std::pin::Pin; use std::task::{Context, Poll}; use tokio::io::AsyncWrite; us

Ivan Nikulin 15 Feb 20, 2024
A crate that allows you to mostly-safely cast one type into another type.

A crate that allows you to mostly-safely cast one type into another type. This is mostly useful for generic functions, e.g. pub fn foo<S>(s: S) {

Bincode 3 Sep 23, 2023
Shell scripting that will knock your socks off

atom Shell scripting that will knock your socks off. NOTE: Click the image above for a video demonstration.

adam mcdaniel 256 Dec 14, 2022
🐢 Atuin replaces your existing shell history with a SQLite database, and records additional context for your commands

Atuin replaces your existing shell history with a SQLite database, and records additional context for your commands. Additionally, it provides optional and fully encrypted synchronisation of your history between machines, via an Atuin server.

Ellie Huxtable 4.6k Jan 1, 2023
a cute shell thingy that written in rust

a cute shell thingy that written in rust

奥田 龍馬 12 Dec 29, 2021
A shell for research papers

Reason: A Shell for Research Papers Did I ever read this paper? Which OSDI 2021 papers did I read? Which ones have the word 'Distributed' in their tit

Jae-Won Chung 121 Nov 27, 2022
Explore from the safety of your shell

turtlescan Explore from the safety of your shell Installation: cargo install turtlescan tui Starts a little tui which connects to your JSON-RPC server

Brian Cloutier 4 Sep 13, 2022
dune - A shell by the beach!

dune - A shell by the beach!

adam mcdaniel 640 Dec 29, 2022
A command-line shell like fish, but POSIX compatible.

A command-line shell like fish, but POSIX compatible.

Seiya Nuta 813 Dec 29, 2022
Zash - A Zuper Awesome Shell

Zash - A Zuper Awesome Shell Welcome to zash, its activily being developed and is not near a stable release. Installation Arch: yay -S zash Paru seem

Robiot 27 May 22, 2022
A very opinionated, zero-configuration shell prompt

A very opinionated, zero-configuration shell prompt

amy null 8 Nov 4, 2021
An interactive shell environment for exploring the p2panda protocol

An interactive shell environment for exploring the p2panda protocol. Uses a mock node and clients to simulate network logic.

null 4 Dec 12, 2021
Self-contained template system with Handlebars and inline shell scripts

Handlematters Self-contained template system with Handlebars and inline shell scripts Introduction Handlematters is a template system that combines Ha

Keita Urashima 3 Sep 9, 2022
A shell Made in rust 🦀

vsh A Blazingly fast shell made in Rust ?? Why make another shell? Because the current leading rust shell is very opinionated, atleast to me. As it br

null 89 Dec 18, 2022
dye is a tool to easily color text in shell.

Dye dye is a tool to easily color text in shell. Usage See the gif below to see these commands in action. echo $(dye --red WARN) This tool will knock

Kurt Wolf 15 Nov 1, 2022
A Unix shell written and implemented in rust 🦀

vsh A Blazingly fast shell made in Rust ?? Installation Copy and paste the following command and choose the appropriate installtion method for you. Yo

XMantle 89 Dec 18, 2022
Shellcheck - a static analysis tool for shell scripts

ShellCheck - A shell script static analysis tool ShellCheck is a GPLv3 tool that gives warnings and suggestions for bash/sh shell scripts: The goals o

Vidar Holen 31.1k Jan 9, 2023
Application microframework with command-line option parsing, configuration, error handling, logging, and shell interactions

Abscissa is a microframework for building Rust applications (either CLI tools or network/web services), aiming to provide a large number of features w

iqlusion 524 Dec 26, 2022
☄🌌️ The minimal, blazing-fast, and infinitely customizable prompt for any shell

☄??️ The minimal, blazing-fast, and infinitely customizable prompt for any shell

Starship Command 31.6k Dec 30, 2022