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.

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

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.

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.

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".

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

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.

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

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.

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

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

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

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).

• [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

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.

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:

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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.