Nushell 0.79

Nushell, or Nu for short, is a new shell that takes a modern, structured approach to your command line. It works seamlessly with the data from your filesystem, operating system, and a growing number of file formats to make it easy to build powerful command line pipelines.

Today, we're releasing version 0.79 of Nu. This release adds a standard library written in nu itself and enhanced IDE support.

Where to get it

Nu 0.79 is available as pre-built binariesopen in new window or from crates.ioopen in new window. If you have Rust installed you can install it using cargo install nu.

NOTE: The optional dataframe functionality is available by cargo install nu --features=dataframe.

As part of this release, we also publish a set of optional plugins you can install and use with Nu. To install, use cargo install nu_plugin_<plugin name>.

Themes of this release / New features

Standard library (@amtoine, @bobhy, @fdncred, @presidento, in new window)

This is it. We finally release the standard library with this 0.79! It's been on the mind of the core team of Nushell for some time and it was made real between the two releases.

But first of all... what is the standard library?

The nushell standard library is a collection of nushell scripts that are automatically loaded in the nushell binary and reachable via the use command without any additional setup.

💡 Note some of the commands from the standard library are used without human intervention as part of what we call the prelude.

As said above, the other commands are available with the use command. The goal of this library is, as its name suggests, to provide a standard experience and a standardized set of commands and tools to any Nushell user. In std, one can find things like

  • a test framework to write robust Nushell scripts, modules and libraries
  • implementation of builtin commands once written in rust
  • logging commands with several log levels
  • ...

💡 Note yes, you heard right, in the future, the standard library might become a sanctuary for non-time-critical commands that were once written in rust as part of the built-in set of commands!

Right now, we are actively trying to move the help commands from the nushell core implementation to the library.

With this release, the library comes with the following custom commands:

std assertopen in new windowa set of commands to write testsassert, assert equal, assert error, assert greater, assert greater or equal, assert length, assert less, assert less or equal, assert not equal, assert skip, assert str contains
std dirsopen in new windowa re-implementation of the shells commandsdirs add, dirs drop, dirs next, dirs prev, dirs show
std helpopen in new windowa Nushell implementation of the built-in commandshelp, help aliases, help commands, help externs, help modules, help operators
std iteropen in new windowan extension of built-in commands to iterate over dataiter filter-map, iter find, iter intersperse, iter scan
std logopen in new windownever miss something in your scriptslog critical, log debug, log error, log info, log warning
xml moduleopen in new windowtools to interact with Xml dataxaccess, xinsert, xtype, xupdate
  • some other commands live under the std namespace, without any module: clip, path add and run-tests


As there has been quite a lot of contributions already (see the 50 closed PRsopen in new window at the time i'm writing this 😮), i'm just gonna give some hints and links in this release note, leaving the rest to the amazing work of other contributors who wrote parts of the lib and its documents (shout out to @bobhyopen in new window, @fdncredopen in new window and @presidentoopen in new window

  • the library can be used and tested with
use std   # will load the whole library under the `std` namespace
use std * #   -    -   -    -      -    without the `std` prefix

or use direct imports, such as

use std 'dirs show'

If, for some reason, you want to load Nushell without the standard library, start nu with the --no-std-lib. This can be the case if you find the startup times much longer than before. We're aiming to improve the loading speed in the future.

enhanced IDE support in our VS code extension (Sophiaopen in new window, fdncredopen in new window)

IDE support

Nushell now has a first LSP (Language Server Protocol)open in new window implementation with a VSCode integration. If you install the latest version of our VSCode pluginopen in new window, you'll see hovers, inlays, tooltips, error squigglies and other features. We are still very early in the LSP development, but the extension is already very usable and definitely moves the experience of writing Nu code to another level!

While currently we have only VSCode integration, the server itself is standalone and we welcome projects adding the LSP support to more editors.

atuin now supports Nushellopen in new window

Thanks to @stevenxxiuopen in new window you can now use atuin with Nushell. We are happy to see Nushell supported by more projects and we welcome PRs adding more integrations.

Relaxed parsing rules (Sophiaopen in new window)

We listened to your feedback around the syntax changes introduced with 0.78 and decided to revert to the old behavior around the parsing rules for numeric literals as well as the compulsory || for closures.

Removed old alias implementation (kubouchopen in new window)

While there are still some missing pieces, we removed the old alias implementation. This means that old-alias is no longer available. We decided to remove it to clean up the code. It makes further fixes to aliases easier as you do not need to remember which alias implementation a piece of code belongs to.

There are two notable missing features from the old aliases:

  • Missing completions with external completers.
  • Most parser keywords (such as source) cannot be aliased but adding support for aliasing them should be possible in most cases.
  • Not possible to alias with environment shorthands (e.g., alias foo = FOO=bar spam)
  • Some presentation issues, such as the output of which and the alias usage pointing at the aliased call instead of the alias itself.

Changes to default files locations (itoopen in new window-hirokiopen in new window)

$nu.config-path and $nu.env-path are now set based on --config and --env-config flags passed to Nushell and also use the path after resolving symlinks. This means that they no longer guarantee pointing at the default Nushell's config directory. To be able to refer to the default config directory, $nu.default-config-dir was added and used in default to always point NU_LIB_DIRS to the scripts directory under the default config directory.

Related to that, $env.CURRENT_FILEopen in new window was added to be able to show the currently evaluated file.

Breaking changes

Full changelog