The PR upgrades nushell to rust version 1.87.0.
## Dev overview from clippy
- I added `result_large_err` to clippy in the root Cargo.toml to avoid
the warnings (and a few places in plugins). At some point a more proper
fix, perhaps boxing these, will need to be performed. This PR is to just
get us over the hump.
- I boxed a couple areas in some commands
- I changed `rdr.bytes()` to `BufReader::new(rdr).bytes()` in nu-json
## Release notes summary - What our users need to know
Users can use rust version 1.87.0 to compile nushell now
## Tasks after submitting
N/A
Change the order of hook evaluations, run `env_change` before `pre_prompt`.
New order of execution is: `env_change` -> `pre_prompt` -> `PROMPT_COMMAND`
# Description
Using `osc 9;4`, `bench` shows a progress bar or circle on supported
terminals, every 10 timing rounds to not degrade performance too much.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
Follow up to #16007
Also added some examples for existing flags which were previously
missing.
After the deprecation period of `--ignore-errors (-i)`, `-i` will be
used as the short form of this flag.
# User-Facing Changes
`get`, `select`, `reject` commands now have a `--ignore-case` flag,
which makes the commands interpret all cell-path arguments as completely
case insensitive.
# Tests + Formatting
+1
# After Submitting
Set a reminder for the `--ignore-errors` deprecation and using `-i` as
the short flag. Maybe we can make PRs in advance for future versions and
mark them with GitHub's milestones.
# Description
Basically, now `null | each { "something" }` will be `null` instead of
`"something"`. Thanks to this, `each` can be used to map values similar
to `map-null` custom commands, for example:
- Before
```nu
let args = if $delay != null {
["--delay" ($delay | format duration sec | parse '{secs} {_}' | get 0.secs)]
} else {
[]
}
```
- After
```nu
let args = (
$delay
| each { ["--delay" ($in | format duration sec | parse '{secs} {_}' | get 0.secs)] }
| default []
)
```
Please let me know if this change messes something up I'm not seeing.
# User-Facing Changes
- Before
```nu
→ null | each { "something" }
something
```
- After
```nu
→ null | each { "something" }
null
```
# Tests + Formatting
Added a test to check for this.
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
As per the suggestion in #16350, this PR moves `random dice` to std.
It's basically a thin wrapper over `random int` already.
# User-Facing Changes (deprecations)
## `random dice` moved to `std`
The `random dice` command has been rewritten in Nushell and moved to the
standard library. The `random dice` built-in is still available with a
deprecation error, but will be removed in 0.108. The new command can be
used as follows:
```nushell
use std/random
random dice
```
It's behavior, parameters, and defaults are the same.
# After Submitting
Update documentation to reflect the change.
Closes#16350
# Description
This PR kills all background jobs on interrupt, as a fix for
https://github.com/nushell/nushell/issues/15947.
# User-Facing Changes
If you run the following: `job spawn { print "job spawned"; ^sleep
infinity }; ^sleep infinity`, then hit ctrl-c, the current behavior is
that the `sleep` process from the job will not be killed, it will
reparented to init. With this change, the process will be killed on
ctrl-c.
# Tests + Formatting
I was unsure of the best way to write a test for this.
# After Submitting
---------
Co-authored-by: 132ikl <132@ikl.sh>
# Description
Currently, when Nushell encounters an unknown flag, it prints all
options in the help string. This is pretty verbose and uses the
`formatted_flags` signature method, which isn't used anywhere else. This
commit refactors the parser to use `did_you_mean` instead, which only
suggest one closest option or sends the user to `help` if nothing close
is found.
# User-Facing Changes (Bug fixes and other changes)
## Improved error messages for misspelled flags
Previously, the help text for a missing flag would list all of them,
which could get verbose on a single line:
```nushell
~> ls --full-path
Error: nu::parser::unknown_flag
× The `ls` command doesn't have flag `full-path`.
╭─[entry #8:1:4]
1 │ ls --full-path
· ─────┬─────
· ╰── unknown flag
╰────
help: Available flags: --help(-h), --all(-a), --long(-l), --short-names(-s), --full-paths(-f), --du(-d), --directory(-D), --mime-type(-m), --threads(-t). Use
`--help` for more information.
```
The new error message only suggests the closest flag:
```nushell
> ls --full-path
Error: nu::parser::unknown_flag
× The `ls` command doesn't have flag `full-path`.
╭─[entry #23:1:4]
1 │ ls --full-path
· ─────┬─────
· ╰── unknown flag
╰────
help: Did you mean: `--full-paths`?
```
---
Closes#16418
# Description
- Implemented `FromValue` for `std::time::Duration`.
- It only converts positive `Value::Duration` values, negative ones
raise `ShellError::NeedsPositiveValue`.
- Refactor `job recv` and `watch` commands to use this implementation
rather than handling it ad-hoc.
- Simplified `watch`'s `debounce` & `debounce-ms` and factored it to a
function. Should make removing `debounce-ms` after its deprecation
period ends.
- `job recv` previously used a numeric cast (`i64 as u64`) which would
result in extremely long duration values rather than raising an error
when negative duration arguments were given.
# User-Facing Changes
Changes in error messages:
- Providing the wrong type (bypassing parse time type checking):
- Before
```
Error: nu:🐚:type_mismatch
× Type mismatch.
╭─[entry #40:1:9]
1 │ watch . --debounce (1 | $in) {|| }
· ──────────┬─────────
· ╰── Debounce duration must be a duration
╰────
```
- After
```
Error: nu:🐚:cant_convert
× Can't convert to duration.
╭─[entry #2:1:9]
1 │ watch . --debounce (1 | $in) {|| }
· ──────────┬─────────
· ╰── can't convert int to duration
╰────
```
- Providing a negative duration value:
- Before
```
Error: nu:🐚:type_mismatch
× Type mismatch.
╭─[entry #41:1:9]
1 │ watch . --debounce -100ms {|| }
· ────────┬────────
· ╰── Debounce duration is invalid
╰────
```
- After
```
Error: nu:🐚:needs_positive_value
× Negative value passed when positive one is required
╭─[entry #4:1:9]
1 │ watch . --debounce -100ms {|| }
· ────────┬────────
· ╰── use a positive value
╰────
```
# Description
Spread operator `...` treats `null` values as empty collections,
, whichever of list or record is appropriate.
# User-Facing Changes
`null` values can be used with the spread operator (`...`)
# Description
Implements `FromValue` and `IntoValue` for `Cow`, which makes it easy to
use it in types that need to implement these traits.
I don't think it will have a significant impact, but it can let us avoid
allocations where we can use static values.
# Tests + Formatting
No need, the implementations are delegated to `B::Owned`.
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
Currently, strings `true` and `false` are intercepted early in parsing.
Previously, if they didn't match the expected shape, the parse error
said "expected non-boolean value". This PR changes the message to say
"expected <shape>".
Because the parsing error requires a `&'static str` I had to add a
`to_str(&self) -> &'static str` method on `SyntaxShape`. It's a bit
crude for more complex shapes: it simply says `keyword`, `list`,
`table`, and so on for them, without exposing the underlying structure.
Fixes#16406
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
Fixes#16409
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
After running `hide-env PATH`, there is a more helpful error and CMD
builtins still work.
<img width="503" height="217" alt="image"
src="https://github.com/user-attachments/assets/a43180f9-5bc2-43bd-9773-aa9ad1818386"
/>
<img width="779" height="253" alt="image"
src="https://github.com/user-attachments/assets/03b59209-f9a9-4c61-9ea2-8fbdc27b8d4b"
/>
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
---------
Co-authored-by: 132ikl <132@ikl.sh>
Works towards #16347 however more work may be required first
# Description
Adds a `--raw` flag to `to html`. This stops the resulting html content
being escaped
# User-Facing Changes
# Tests + Formatting
# After Submitting
Refs
https://discord.com/channels/601130461678272522/615329862395101194/1403760147985207487
# Description
Currently `watch` doesn't normally return, ever. The only way to stop it
is to abort with `Ctrl+C` (or some internal error happens), so it never
produces a usable pipeline output. Since nu doesn't have `never` type
yet, `nothing` is the closest thing we can use.
# User-Facing Changes
Users may start to get type errors if they used `watch .... | something`
and the `something` did not accept `nothing`.
# Tests + Formatting
All pass.
# Description
The existing examples cover how to send data to a job, but I think it
will be much more common to want to receive data from a job.
# User-Facing Changes
Just documentation, though it may be worth highlighting anyway. I really
thought for a while that this was not possible yet. See also my book PR
https://github.com/nushell/nushell.github.io/pull/2006 (`job send` and
`job recv` were not documented in the book at all).
Refs
https://discord.com/channels/601130461678272522/614593951969574961/1403435414416654427
# Description
Previously Example result values would have a test span, which would
cause hard to understand errors for the code that uses `scope commands`.
Now they will have the span that points to `scope commands` invocation.
# User-Facing Changes
Errors referencing example results will get slightly better.
# Tests + Formatting
All pass.
# Description
In #16354, I introduced a bug thinking that `table -e` would always
return a string, so I fix it here restoring the `to text`. While I was
at it, I changed all instances of `if not ($var | is-empty)` to `if
($var | is-not-empty)` to improve readability.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
Fixes: #16040
# Description
TBH, I not a fan of this whole `parse_external_string` idea.
Maybe I lack some of the background knowledge here, but I don't see why
we choose not to
1. parse external arguments the same way as internal ones
2. treat them literally at runtime if necessary
Tests: +1
# Description
Trying to parse non-UTF8 data as a value with unit (part of every
literal parse) introduced a replacement character which shifted the span
information so the indices where incorrect and triggered
a panic.
This has been resolved by removing a bad `String::from_utf8_lossy`
# User-Facing Changes
One less possible panic
# Tests + Formatting
Added a test with the original reproducer from fuzzing:
File with `0\xffB` where the `\xff` represents the non utf-8 char `FF`
run as a script to trigger
- related #16258
# Description
In #16258 we had some trouble getting tests to work properly. After some
investigation with @WindSoilder we figured out that `Table::new` inside
`into_sqlite.rs` did not respect the `$env.PWD`. The underlying
`open_sqlite_db` and in that `Connection::open` respects the current
working directory. That one is updated via `cd` but not necessarily in
tests (and we should not try that). In this PR I join the `$env.PWD`
with the path passed to `into sqlite`.
This PR also adds a test for the auto conversion from #16258.
# User-Facing Changes
Should be none, some edge cases might be fixed now.
# Description
Added trimming to the example results like in the normal `help`, and
also changed the logic for binary examples to remove the weird spacing.
- Before:
<img width="998" height="919" alt="image"
src="https://github.com/user-attachments/assets/03f18f45-5b12-41bc-b495-232bcf899964"
/>
- After:
<img width="959" height="720" alt="image"
src="https://github.com/user-attachments/assets/894dc622-c603-467c-8904-aef582a82b0a"
/>
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
The `help` command, when printing the examples with results, trims the
first line and it appears unindented compared to the following lines.
- Before:
<img width="1110" height="346" alt="image"
src="https://github.com/user-attachments/assets/3487381d-3631-49c9-bb0e-f7ad958b7291"
/>
- After:
<img width="1123" height="339" alt="image"
src="https://github.com/user-attachments/assets/acb45afd-0492-49d2-a5cb-5130bbb4cf94"
/>
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
Adds `random choice` suggested in #16241.
# User-Facing Changes
New `random` module in `std-rfc` with the `choice` subcommand.
# Tests + Formatting
Unsure how do to do tests. Sampling and a histogram should be enough,
but they'll be non-deterministic.
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
---------
Co-authored-by: sholderbach <sholderbach@users.noreply.github.com>
# Description
Changes the behavior of `--ignore-case` and `--multiline` options for
`find`, to make them more consistent between regex mode and search term
mode, and to enable more options for using find.
# User-Facing Changes
Search term mode is now case-sensitive by default.
`--ignore-case` will make the search case-insensitive in search term
mode. In regex mode, the previous behavior of adding a (?i) flag to the
regex is preserved.
`--multiline` will no longer add a (?m) flag in regex mode. Instead, it
will make the search not split multi-line strings into lists of lines.
closes#16317closes#16022
# Description
`explore` was reading the byte length for computing:
- `:` command input cursor positions
- `/`/`?` search mode cursor positions
- `:try` input box cursor positions
- search highlighting
Fixed this for the majority of cases by using `unicode_width`, this is
only best effort as terminals don't need to follow those expectations
but for the most cases (traditional language scripts etc.) this should
lead to better result. The only way around the uncertainty would be to
perform the highlighting/cursor marking as we go, but this may not be as
compatible with the `ratatui` framework.
Closes#16312
# User-Facing Changes
Fixed cursor position and search highlighting for non-ASCII characters,
with the caveat mentioned above.
# Tests + Formatting
Manually tested
# Description
Allows custom bindings (non-chord) to send a `edit_mode: vi` mode change
via the new `ReedlineEvent::ViChangeMode`
Takes https://github.com/nushell/reedline/pull/932
# User-Facing Changes
You can now set bindings which change the Vi mode. (This still has the
same rules for defining the key-combination: Only modifiers and single
keys are supported)
To do so send a `vichangemode` event with the `mode` field to set
`normal`, `insert`, or `visual`
```nushell
$env.config.keybindings ++=
[{
name: modechangetest
modifier: control
keycode: "char_["
mode: [vi_normal, vi_insert]
event: {send: vichangemode, mode: normal}
}]
```
# Description
Adds an example that documents how to use `input --reedline` to collect
multiple lines of input from the user
I also removed an extraneous and inconsistent space in the following
example.
# User-Facing Changes
Documentation addition
# Tests + Formatting
I did not run any tests or autoformatters because of the docs-only
nature of the change, and the fact that I copy-pasted the format from an
existing example. If the autoformatter is unhappy, I apologize.
# After Submitting
This PR should automatically update the docs site at the next release,
so no need to do anything there.
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
# Description
As title, this pr introduce `-h` flag to testbin, so if I want to see
which testbin I should use, I don't need to look into source code.
### About the change
I don't know if there is any way to get docstring of a function inside
rust code. So I created a trait, and put docstring into it's `help`
method:
```rust
pub trait TestBin {
// the docstring of original functions are moved here.
fn help(&self) -> &'static str;
fn run(&self);
}
```
Take `cococo` testbin as example, the changes are:
```
original cococo function --> Cococo struct, then
1. put the body of `cococo` function into `run` method
2. put the docstring of `cococo` function into `help` method
```
# User-Facing Changes
`-h/--help` flag in testbin is enabled.
```
> nu --testbin -h
Usage: nu --testbin <bin>
<bin>:
chop -> With no parameters, will chop a character off the end of each line
cococo -> Cross platform echo using println!()(e.g: nu --testbin cococo a b c)
echo_env -> Echo's value of env keys from args(e.g: nu --testbin echo_env FOO BAR)
echo_env_mixed -> Mix echo of env keys from input(e.g: nu --testbin echo_env_mixed out-err FOO BAR; nu --testbin echo_env_mixed err-out FOO BAR)
echo_env_stderr -> Echo's value of env keys from args to stderr(e.g: nu --testbin echo_env_stderr FOO BAR)
echo_env_stderr_fail -> Echo's value of env keys from args to stderr, and exit with failure(e.g: nu --testbin echo_env_stderr_fail FOO BAR)
fail -> Exits with failure code 1(e.g: nu --testbin fail)
iecho -> Another type of echo that outputs a parameter per line, looping infinitely(e.g: nu --testbin iecho 3)
input_bytes_length -> Prints the number of bytes received on stdin(e.g: 0x[deadbeef] | nu --testbin input_bytes_length)
meow -> Cross platform cat (open a file, print the contents) using read_to_string and println!()(e.g: nu --testbin meow file.txt)
meowb -> Cross platform cat (open a file, print the contents) using read() and write_all() / binary(e.g: nu --testbin meowb sample.db)
nonu -> Cross platform echo but concats arguments without space and NO newline(e.g: nu --testbin nonu a b c)
nu_repl -> Run a REPL with the given source lines
relay -> Relays anything received on stdin to stdout(e.g: 0x[beef] | nu --testbin relay)
repeat_bytes -> A version of repeater that can output binary data, even null bytes(e.g: nu --testbin repeat_bytes 003d9fbf 10)
repeater -> Repeat a string or char N times(e.g: nu --testbin repeater a 5)
```
# Tests + Formatting
None, all existed tests can guarantee the behavior of testbins doesn't
change.
# After Submitting
NaN
# Description
Fixes#15485
This PR changes pipeline checking to keep track of all possible output
types instead of only first type matching input type which appears in
the input/output types. For example, in this command:
```nushell
def foo []: [int -> string, int -> record] {
# ...
}
```
An `int` input to the command may result in a string or a record to be
output. Before this PR, Nushell would always assume that an `int` input
would cause a `string` output because it's the first matching
input/output type pair. This would cause issues during type checking
where the parser would incorrectly determine the output type. After this
PR, Nushell considers the command to output either a string or a record.
# User-Facing Changes
* Parse-time pipeline type checking now properly supports commands with
multiple pipeline output types for the same pipeline input type
# Tests + Formatting
Added a couple tests
# After Submitting
N/A
---------
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
# Description
As title: this pr is try to introduce 2 functions to `PipelineData`:
1. PipelineData::list_stream --> create a PipelineData::ListStream
2. PipelineData::byte_stream -> create a PipelineData::ByteStream
And use these functions everywhere.
### Reason behind this change
I tried to implement `pipefail` feature, but this would required to
change `PipelineData` from enum to struct. So use these functions can
reduce diff if I finally change to struct. [Discord message
here](https://discord.com/channels/601130461678272522/615962413203718156/1396999539000479784)
is my plan.
# User-Facing Changes
NaN
# Tests + Formatting
NaN
# After Submitting
NaN
- fixes#16200
# Description
| | Select | Fuzzy |
| -- | ---------------- | --------------- |
| ❌ | ![select-before] | ![fuzzy-before] |
| ✅ | ![select-fixed] | ![fuzzy-fixed] |
[select-before]:
8fe9136472/select-before.svg
[select-fixed]:
8fe9136472/select-after.svg
[fuzzy-before]:
8fe9136472/fuzzy-before.svg
[fuzzy-fixed]:
8fe9136472/fuzzy-after.svg
Using a custom `dialoguer::theme::Theme` implementation, how `input
list` renders items are overridden.
Unfortunately, implementing one of the methods requires
`fuzzy_matcher::skim::SkimMatcherV2` which `dialoguer` does not export
by itself.
Had to add an explicit dependency to `fuzzy_matcher`, which we already
depend on through `dialoguer`. Version specification is copied from
`dialoguer`.
# Tests + Formatting
No tests added.
Couldn't find existing tests, not sure how to test this.
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
Fix commit ID hex formatting in gstat, closes#16307
Leading zeros are preserved, maintaining the correct hex representation
This issue is relatively easy to fix, but it's not very easy to verify.
However, I have already tested several scenarios, it works for commit
sha like `000baeef`, `000003c7` and `00000002` etc.
Fixes#16185
# Description
Stepped range literals where `..=` precedes the second value no longer
cause a parser panic:
```diff
random int 1..=3..5
-Error: x Main thread panicked.
- |-> at crates/nu-protocol/src/engine/state_working_set.rs:400:48
- `-> slice index starts at 8 but ends at 7
+Error: nu::parser::parse_mismatch
+
+ × Parse mismatch during operation.
+ ╭─[entry #1:1:15]
+ 1 │ random int 1..=3..5
+ · ─┬
+ · ╰── expected number
```
Currently we run this locally on whatever machine the person doing it is
using. With this we have all three major platforms covered and don't
block a personal machine before the release. Also any failures are
visible to everyone if we need to fix something.
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
As a bonus to #16174, I realized it would be trivial to add a similar
check to where.
Before:
```nushell
1..100 | where 1
# => no output...
```
After:
```nushell
1..100 | where 1
# => Error: nu::parser::type_mismatch
# =>
# => × Type mismatch.
# => ╭─[entry #3:1:16]
# => 1 │ 1..100 | where 1
# => · ┬
# => · ╰── expected bool, found int
# => ╰────
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* `where` should now error on row condition expressions which are not
booleans
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Added test
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
N/A
Restricts custom completion from universal to internal arguments only.
Pros:
1. Less memory
2. More flexible for later customizations, e.g. #14923
Cons:
1. limited customization capabilities, but at least covers all currently
existing features in nushell.
# Description
Mostly vibe coded by [Zed AI](https://zed.dev/ai) with a single prompt.
LGTM, but I'm not so sure @ysthakur
# User-Facing Changes
Hopefully none.
# Tests + Formatting
+3
# After Submitting
---------
Co-authored-by: Yash Thakur <45539777+ysthakur@users.noreply.github.com>
- fixes#16129
# Description
## Problem
Parsing a multi span value as RowCondition always produces a RowCondition
expression that covers all the spans.
Which is problematic inside OneOf and can produce multiple expressions with
overlapping spans.
Which results in funky highlighting that duplicates text.
## Solution
Only reason for including `SyntaxShape::Closure` in the signature (#15697) was
for documentation purposes, making it clear in `help` texts that a closure can
be used as the argument.
As our current parser is shape directed, simplifying the command signature
means simplifies the parsing, so using a RowCondition on its own, and instead
making it always look like a union with `closure(any)` solves the issue without
any changes in the parser.
Also, RowCondition always accepts closure values anyway, so its textual
representation should indicate that without the need to wrap it in OneOf.
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
This code didn't compile, fixed provisionally by always running the
codepath with tilde expansion.
@IanManske worth discussing what we may want to fuzz here.
This pull request fixes a typo in the description of a `glob` example:
**Before:**
```
Search for files for folders that do not begin with c, C, b, M, or s
> glob "[!cCbMs]*"
```
**After:**
```
Search for files or folders that do not begin with c, C, b, M, or s
> glob "[!cCbMs]*"
```
cc: @blindFS @ysthakur
# Description
Enable `nucleo`'s `prefer_prefix` configuration option.
Ranks suggestions with matches closer to the start higher than
suggestions that have matches further from the start.
Example: suggestions based on `reverse`:
<table>
<tr>
<td width=200>Before</td>
<td width=200>After</td>
</tr>
<tr>
<td>
```
bytes reverse
polars reverse
reverse
str reverse
```
</td>
<td>
```
reverse
str reverse
polars reverse
bytes reverse
```
</td>
</tr>
</table>
# User-Facing Changes
More relevant suggestions with fuzzy matching algorithm.
(`$env.config.completions.algorithm = "fuzzy"`)
# Tests + Formatting
We might want to add tests to make sure this option keeps working in the
future.
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
Fixes#15308. Surprisingly, I can't find any more issues that bring this
up.
This PR adds a check for interrupt before evaluating each IR
instruction. This makes it possible to ctrl-c out of things that were
difficult/impossible previously, like:
```nushell
loop {}
```
@devyn also [mentioned
previously](https://discord.com/channels/601130461678272522/615329862395101194/1268674828492083327)
that this might be a feasible option, but mentioned some performance
concerns.
I did some benchmarking previously but it turns out tango isn't the
greatest for this. I don't have hard numbers anymore but based on some
experimenting I shared in the Discord it seems like no experimental
option and limiting this to specific instructions should keep the
performance impact minimal.
<details>
<summary>Old benchmarking info</summary>
I did some benchmarks against main. It seems like most benchmarks are
between 1-6% slower, with some oddball exceptions.
The worst case seems to a giant loop, which makes sense since it's
mostly just jumping back to the beginning, meaning we hit the check over
and over again.
With `bench --pretty -n 100 { for i in 0..1000000 { 1 } }`, it seems
like the `ir-interrupt` branch is ~10% slower for this stress case:
```
main: 94ms 323µs 29ns +/- 1ms 291µs 759ns
ir-interrupt: 103ms 54µs 708ns +/- 1ms 606µs 571ns
(103ms + 54µs + 708ns) / (94ms + 323µs + 29ns) = 1.0925720801438639
```
The performance numbers here aren't great, but they're not terrible
either, and I think the usability improvement is probably worth it here.
<details>
<summary>Tango benchmarks</summary>
```
load_standard_lib [ 2.8 ms ... 2.9 ms ] +3.53%*
record_create_1 [ 101.8 us ... 107.0 us ] +5.12%*
record_create_10 [ 132.3 us ... 135.6 us ] +2.48%*
record_create_100 [ 349.7 us ... 354.6 us ] +1.39%*
record_create_1000 [ 3.7 ms ... 3.6 ms ] -1.30%
record_flat_access_1 [ 94.8 us ... 99.9 us ] +5.35%*
record_flat_access_10 [ 96.2 us ... 101.3 us ] +5.33%*
record_flat_access_100 [ 106.0 us ... 111.4 us ] +5.07%*
record_flat_access_1000 [ 203.0 us ... 208.5 us ] +2.69%
record_nested_access_1 [ 95.3 us ... 100.1 us ] +5.03%*
record_nested_access_2 [ 98.4 us ... 104.6 us ] +6.26%*
record_nested_access_4 [ 100.8 us ... 105.4 us ] +4.56%*
record_nested_access_8 [ 104.7 us ... 108.1 us ] +3.23%
record_nested_access_16 [ 110.6 us ... 115.8 us ] +4.71%*
record_nested_access_32 [ 119.0 us ... 124.0 us ] +4.20%*
record_nested_access_64 [ 137.4 us ... 142.2 us ] +3.47%*
record_nested_access_128 [ 176.7 us ... 181.8 us ] +2.87%*
record_insert_1_1 [ 106.2 us ... 111.9 us ] +5.35%*
record_insert_10_1 [ 111.2 us ... 116.0 us ] +4.28%*
record_insert_100_1 [ 134.3 us ... 139.8 us ] +4.06%*
record_insert_1000_1 [ 387.8 us ... 417.1 us ] +7.55%
record_insert_1_10 [ 162.9 us ... 171.5 us ] +5.23%*
record_insert_10_10 [ 159.5 us ... 166.2 us ] +4.23%*
record_insert_100_10 [ 183.3 us ... 190.7 us ] +4.04%*
record_insert_1000_10 [ 411.7 us ... 418.7 us ] +1.71%*
table_create_1 [ 117.2 us ... 120.3 us ] +2.66%
table_create_10 [ 144.9 us ... 152.2 us ] +5.02%*
table_create_100 [ 476.0 us ... 484.8 us ] +1.86%*
table_create_1000 [ 3.7 ms ... 3.7 ms ] +1.55%
table_get_1 [ 121.6 us ... 127.0 us ] +4.40%*
table_get_10 [ 112.1 us ... 117.4 us ] +4.71%*
table_get_100 [ 124.0 us ... 129.5 us ] +4.41%*
table_get_1000 [ 229.9 us ... 245.5 us ] +6.75%*
table_select_1 [ 111.1 us ... 115.6 us ] +4.03%*
table_select_10 [ 112.1 us ... 118.4 us ] +5.65%*
table_select_100 [ 142.2 us ... 147.2 us ] +3.53%*
table_select_1000 [ 383.5 us ... 370.3 us ] -3.43%*
table_insert_row_1_1 [ 122.5 us ... 127.8 us ] +4.35%*
table_insert_row_10_1 [ 123.6 us ... 128.6 us ] +3.99%*
table_insert_row_100_1 [ 124.9 us ... 131.2 us ] +5.05%*
table_insert_row_1000_1 [ 177.3 us ... 182.7 us ] +3.07%*
table_insert_row_1_10 [ 225.7 us ... 234.5 us ] +3.90%*
table_insert_row_10_10 [ 229.2 us ... 235.4 us ] +2.69%*
table_insert_row_100_10 [ 253.3 us ... 257.6 us ] +1.69%
table_insert_row_1000_10 [ 311.1 us ... 318.3 us ] +2.32%*
table_insert_col_1_1 [ 107.6 us ... 113.3 us ] +5.35%*
table_insert_col_10_1 [ 109.6 us ... 115.3 us ] +5.27%*
table_insert_col_100_1 [ 155.5 us ... 159.8 us ] +2.71%*
table_insert_col_1000_1 [ 476.6 us ... 480.8 us ] +0.88%*
table_insert_col_1_10 [ 167.7 us ... 177.4 us ] +5.75%
table_insert_col_10_10 [ 178.5 us ... 194.8 us ] +9.16%*
table_insert_col_100_10 [ 314.4 us ... 322.3 us ] +2.53%*
table_insert_col_1000_10 [ 1.7 ms ... 1.7 ms ] +1.35%*
eval_interleave_100 [ 485.8 us ... 506.5 us ] +4.27%
eval_interleave_1000 [ 3.3 ms ... 3.2 ms ] -1.51%
eval_interleave_10000 [ 31.5 ms ... 31.0 ms ] -1.80%
eval_interleave_with_interrupt_100 [ 473.2 us ... 479.6 us ] +1.35%
eval_interleave_with_interrupt_1000 [ 3.2 ms ... 3.2 ms ] -1.26%
eval_interleave_with_interrupt_10000 [ 32.3 ms ... 31.1 ms ] -3.81%
eval_for_1 [ 124.4 us ... 130.1 us ] +4.60%*
eval_for_10 [ 124.4 us ... 130.3 us ] +4.80%*
eval_for_100 [ 134.5 us ... 141.5 us ] +5.18%*
eval_for_1000 [ 222.7 us ... 244.0 us ] +9.59%*
eval_for_10000 [ 1.0 ms ... 1.2 ms ] +13.86%*
eval_each_1 [ 146.9 us ... 153.0 us ] +4.15%*
eval_each_10 [ 152.3 us ... 158.8 us ] +4.26%*
eval_each_100 [ 169.3 us ... 175.6 us ] +3.76%*
eval_each_1000 [ 346.8 us ... 357.4 us ] +3.06%*
eval_each_10000 [ 2.1 ms ... 2.2 ms ] +2.37%*
eval_par_each_1 [ 194.3 us ... 203.5 us ] +4.73%*
eval_par_each_10 [ 186.4 us ... 193.1 us ] +3.59%*
eval_par_each_100 [ 213.5 us ... 222.2 us ] +4.08%*
eval_par_each_1000 [ 433.4 us ... 437.4 us ] +0.93%
eval_par_each_10000 [ 2.4 ms ... 2.4 ms ] -0.40%
eval_default_config [ 406.3 us ... 414.9 us ] +2.12%*
eval_default_env [ 475.7 us ... 495.1 us ] +4.08%*
encode_json_100_5 [ 132.7 us ... 128.9 us ] -2.88%*
encode_json_10000_15 [ 35.5 ms ... 34.0 ms ] -4.15%*
encode_msgpack_100_5 [ 85.0 us ... 83.9 us ] -1.20%*
encode_msgpack_10000_15 [ 22.2 ms ... 21.7 ms ] -2.17%*
decode_json_100_5 [ 431.3 us ... 421.0 us ] -2.40%*
decode_json_10000_15 [ 119.7 ms ... 117.6 ms ] -1.76%*
decode_msgpack_100_5 [ 160.6 us ... 151.1 us ] -5.90%*
decode_msgpack_10000_15 [ 44.0 ms ... 43.1 ms ] -2.12%*
```
</details>
</details>
# User-Facing Changes
* It should be possible to ctrl-c in situations where it was not
previously possible
# Tests + Formatting
N/A
# After Submitting
N/A
# Description
Type-check all closure arguments, not just required arguments.
Not doing so looks like an oversight.
# User-Facing Changes
Previously, passing an argument of the wrong type to a closure would
fail if the argument is required, but be accepted (ignoring the type
annotation) if the argument is optional:
```
> do {|x: string| $x} 4
Error: nu:🐚:cant_convert
× Can't convert to string.
╭─[entry #13:1:21]
1 │ do {|x: string| $x} 4
· ┬
· ╰── can't convert int to string
╰────
> do {|x?: string| $x} 4
4
> do {|x?: string| $x} 4 | describe
int
```
It now fails the same way in both cases.
# Tests + Formatting
Added tests, the existing tests still pass.
Please let me know if I added the wrong type of test or added them in
the wrong place (I didn't spot similar tests in the nu-cmd-lang crate,
so I put them next to the most-related existing tests I could find...
# After Submitting
I think this is minor enough it doesn't need a doc update, but please
point me in the right direction if not.
# Description
This script as example for demonstration
```nushell
def miku [] { print "Hiii world! 初音ミクはみんなのことが大好きだよ！" }
def main [leek: int, fn: closure] {
print $"Miku has ($leek) leeks 🩵"
do $fn
}
```
---
`escape_for_string_arg` quoting strings misses, where `|` and `;` did
split the command into 2+ commands
```console
~:► nu ./miku.nu '32' '{miku}'
Miku has 32 leeks 🩵
Hiii world! 初音ミクはみんなのことが大好きだよ！
~:► nu ./miku.nu '32' '{miku};ls|' where type == dir
Miku has 32 leeks 🩵
Hiii world! 初音ミクはみんなのことが大好きだよ！
╭────┬─────────────┬──────┬────────┬──────────────╮
│ # │ name │ type │ size │ modified │
├────┼─────────────┼──────┼────────┼──────────────┤
│ 0 │ Desktop │ dir │ 4.0 kB │ 5 months ago │
│ 1 │ Documents │ dir │ 4.0 kB │ a day ago │
│ 2 │ Downloads │ dir │ 4.0 kB │ a day ago │
│ 3 │ Music │ dir │ 4.0 kB │ 9 months ago │
│ 4 │ Pictures │ dir │ 4.0 kB │ 3 weeks ago │
│ 5 │ Public │ dir │ 4.0 kB │ 9 months ago │
│ 6 │ Templates │ dir │ 4.0 kB │ 3 months ago │
│ 7 │ Videos │ dir │ 4.0 kB │ 9 months ago │
│ 8 │ __pycache__ │ dir │ 4.0 kB │ 3 weeks ago │
│ 9 │ bin │ dir │ 4.0 kB │ 3 days ago │
│ 10 │ repos │ dir │ 4.0 kB │ a day ago │
│ 11 │ trash │ dir │ 4.0 kB │ 3 days ago │
╰────┴─────────────┴──────┴────────┴──────────────╯
```
# User-Facing Changes
This adjustment won't need a change, aside from clarifying the following
behavior, which is unintuitive and potentially ambiguous
```console
~:► nu ./miku.nu '32' {miku}
Miku has 32 leeks 🩵
Hiii world! 初音ミクはみんなのことが大好きだよ！
~:► nu ./miku.nu '32' { miku }
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[<commandline>:1:9]
1 │ main 32 "{ miku }"
· ─────┬────
· ╰── expected block, closure or record
╰────
~:► nu ./miku.nu '32' '{' miku '}'
Miku has 32 leeks 🩵
Hiii world! 初音ミクはみんなのことが大好きだよ！
```
# Description
I added a debug-only check that makes sure only non-other I/O errors get
converted.
Since tests run in debug mode, that should help us catch these errors early.
I left the check out in release mode on purpose so we don't crash users who
have nu as their main shell. It's similar to the debug assertions in the same
file that check for unknown spans.
# Description
This PR depends on #16147, use `git diff 132ikl/shell-warning
132ikl/isolation-warn` to see only changes from this PR
People seem to get tripped up by this a lot, and it's not exactly
intuitive, so I added a warning if you try to set
`$env.config.history.isolation = true` when using the plaintext file
format:
Warning: nu:🐚:invalid_config
⚠ Encountered 1 warnings(s) when updating config
Warning: nu:🐚:incompatible_options
⚠ Incompatible options
╭─[source:1:33]
1 │ $env.config.history.isolation = true
· ──┬─
· ╰── history isolation only compatible with SQLite format
╰────
help: disable history isolation, or set $env.config.history.file_format = "sqlite"
# User-Facing Changes
* Added a warning when using history isolation without using SQLite
history.
# Tests + Formatting
Added a test
# Description
Adds a proper `ShellWarning` enum which has the same functionality as
`ParseWarning`.
Also moves the deprecation from #15806 into `ShellWarning::Deprecated`
with `ReportMode::FirstUse`, so that warning will only pop up once now.
# User-Facing Changes
Technically the change to the deprecation warning from #15806 is user
facing but it's really not worth listing in the changelog
# Description
This PR adds error output display for stdlib tests. This makes it easier
to understand why a test is failing. Here's what an example error output
looks like:
# User-Facing Changes
N/A
# Tests + Formatting
N/A
# After Submitting
N/A
# Description
Before this PR, errors without error codes are printed somewhat
strangely, with the `×` and the description being printed on the same
line as the `Error:` text:
Error: × Invalid literal
╭─[entry #1:1:2]
1 │ "\z"
· ─┬─
· ╰── unrecognized escape after '\' in string
╰────
This PR adds a default error code for the different error types:
Error: nu::parser::error
× Invalid literal
╭─[entry #1:1:2]
1 │ "\z"
· ─┬─
· ╰── unrecognized escape after '\' in string
╰────
While maybe not as informative as a proper error code, it makes
`GenericError`s and other things which don't have error codes look a lot
nicer.
It would be nicer if we could just set `diagnostic(code:
"nu:🐚:error")` at the top of `ShellError`, but unfortunately you
can't set a "default" at the `enum` level and then override it in the
variants. @cptpiepmatz mentioned he might change miette's derive macro
to accommodate this, in that case we can switch the approach here.
# User-Facing Changes
* Errors without error codes now have a default error code corresponding
to from which part of Nushell the error occurred (shell, parser,
compile, etc)
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
As decided on the team meeting on 2025-06-19, rename `--ignore-errors
(-i)` to `--optional (-o)` with a (currently) indefinite grace period.
After `--ignore-errors (-i)` is removed, the short flag `-i` can be used
for `--ignore-case` (not implemented as of this PR)
# User-Facing Changes
`get`/`select`/`reject`: rename `--ignore-errors (-i)` to `--optional
(-o)` to better reflect its behavior.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
Update docs and inform third parties that integrate with nushell.
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
#16075
# Description
# User-Facing Changes
Improved experience: more meaningful items on top of the completion
menu.
Mostly for the fuzzy/substring matcher.
# Tests + Formatting
Adjusted
# After Submitting
# Description
Adds an `extern` definition (`KnownExternal`) for the `nu` command. This
way you can do `help nu` and get tab completions for flags on the `nu`
executable
# User-Facing Changes
* You can now view the flags for Nushell itself with `help nu`, and tab
completion for flags on `nu` works
# Description
Partially handles #14799
It's difficult to fix all cases there, but I think it's good to improve
one of this with a small step
# User-Facing Changes
Given the following code in c:
```C
// write.c
#include <stdio.h>
int main() {
while (1) {
printf("a\n");
}
}
```
After this pr, `./write | 0` will exit immediately, in that case,
`./write` will receive `SIGPIPE` in unix. Before this pr, `./write | 0`
runs indefinitely.
-----------------------
Maybe it's easier to see what happened internally by the different
output of `view ir { ./write | 0 }` command.
### Before
```
# 2 registers, 6 instructions, 7 bytes of data
0: load-literal %1, glob-pattern("./write", no_expand = false)
1: push-positional %1
2: redirect-out null
3: call decl 135 "run-external", %0
4: load-literal %0, int(0)
5: return %0
```
### After
```
# 2 registers, 6 instructions, 7 bytes of data
0: load-literal %1, glob-pattern("./write", no_expand = false)
1: push-positional %1
2: redirect-out pipe # changed, the command's output is a pipe rather than null
3: call decl 136 "run-external", %0
4: load-literal %0, int(0)
5: return %0
```
# Tests + Formatting
Added 1 test.
# After Submitting
NaN
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
- closes#16159
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
The setup in #16159 produced a `ByteStream` that held the `ShellError`
inside an `std::io::Error`. For exactly this setup is the
`ShellErrorBridge` designed, while figuring out what happened I found
out that inside `BytesStream::into_bytes` a sneaky `ShellErrorBridge`
was hiding:
<img width="1034" height="580" alt="image"
src="https://github.com/user-attachments/assets/a0d16ca6-1a60-4c3c-a4cb-5e4b0695f20c"
/>
To fix this, I try to unwrap the bridge and if that is possible, return
the original `ShellError`. This is done at multiple occasions inside
`byte_stream.rs` already.
With this fix, we get the original error that looks like this:
<img width="1439" height="733" alt="image"
src="https://github.com/user-attachments/assets/73f4dee7-f986-4f68-9c2c-0140a6e9e2b2"
/>
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
None, just a better error.
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
To have less situations with other I/O errors, I opened #16160 to find
out faster what other error was passed around.
- fixes#5986
- fixes#7760
- fixes#8856
- fixes#10592
- fixes#11082
# Description
Unconditionally update the config state after each `overlay use` and
`overlay hide`.
The fix looks simple, but only because of the constant improvements and
refactors to the codebase that have taken place over time made it
possible.
Fixing these issue when they were initially filed would have been much
harder.
# User-Facing Changes
Overlays can add hooks, change color_config, update the config in
general.
# Tests + Formatting
No tests added as I still haven't figured out how to simulate the repl
in tests.
# After Submitting
N/A
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
Cell-path accesses on `null` values throw an error, unless the initial
cell-path member is optional:
```nushell
">"; (null).a
# => Error: nu:🐚:incompatible_path_access
# =>
# => x Data cannot be accessed with a cell path
# => ,-[source:1:8]
# => 1 | (null).a
# => : |
# => : `-- nothing doesn't support cell paths
# => `----
">"; (null).a? | describe
# => nothing
```
`get` throws an error on `null` even when the cell-path is optional, and
only returns `null` quietly with the `--ignore-errors` flag
```nushell
">"; null | get a?
# => Error: nu:🐚:only_supports_this_input_type
# =>
# => x Input type not supported.
# => ,-[source:1:1]
# => 1 | null | get a?
# => : ^^|^ ^|^
# => : | `-- only table or record input data is supported
# => : `-- input type: nothing
# => `----
">"; null | get -i a? | describe
# => nothing
```
# Tests + Formatting
No breakage.
# After Submitting
N/A
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
This updates to the latest reedline 405299b to include
https://github.com/nushell/reedline/pull/898 for dogfooding.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
Changes miette warnings to use `Severity::Warning` instead of the
default `Severity::Error`. This shows them in a different color and with
a different icon:
<img width="650" height="266" alt="image"
src="https://github.com/user-attachments/assets/3ff0d3cf-ab1e-47f2-aff7-586ecea5a32a"
/>
# User-Facing Changes
* Warnings now look less like errors
these documentations say ">" when what they mean is ">>"
# Description
this documentation is about the use of ">>", but the documentation
wrongly says ">". it has been updated to say ">>" instead.
# User-Facing Changes
the user will see ">>" in the documentation instead of ">".
# Tests + Formatting
there is nothing to test. this is a documentation change.
# After Submitting
# Description
Conversion from `AnyType::DatetimeOwned` was missing, so datetime
objects could not be represented in Nushell Values. This adds the
conversion.
A slight refactor of the `datetime_from_epoch_nanos` was needed.
# User-Facing Changes
All datetime types can be represented in Nushell.
> Further tests are welcomed.
It was already implemented that we precalculate widths, but nothing
stops to do heights as well.
Because before all the calculus were wasted (literally).
It affects `table` and `table --expand`.
The only case when it does not work (even makes things slightly less
optimal in case of `table` when `truncation` is used)
Sadly my tests are not showing the clear benefit.
I have no idea why I was expecting something 😞
But it must be there :)
Running `scope commands` + `$env.CMD_DURATION_MS`:
```log
# patch (release)
2355 2462 2210 2356 2303
# main (release)
2375 2240 2202 2297 2385
```
PS: as once mentioned all this stuff ought to be moved out `nu-table`
---------
Signed-off-by: Maxim Zhiburt <zhiburt@gmail.com>
- closes#16118
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR adds the option to pass `all` to the experimental options
parser. This will enable all active (not deprecated) experimental
options to ease with dogfooding.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
A new valid value for `--experimental-options` and
`NU_EXPERIMENTAL_OPTIONS`.
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
This fixes an oversight where not all items show in `ansi --list`.
### Before
### After
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Rel: #14429, #16079
Finishes up a TODO in the assignment type checking.
- For regular assignment operations (only applies to `mut`), type
checking is now done using `type_compatible` (which is what `let` uses)
- This allows some mutable assignments to work which weren't allowed
before
Before:
```nushell
let x: glob = ""
# => ok, no error
mut x: glob = ""; $x = ""
# => Error: nu::parser::operator_incompatible_types
# =>
# => × Types 'glob' and 'string' are not compatible for the '=' operator.
# => ╭─[entry #6:1:19]
# => 1 │ mut x: glob = ""; $x = ""
# => · ─┬ ┬ ─┬
# => · │ │ ╰── string
# => · │ ╰── does not operate between 'glob' and 'string'
# => · ╰── glob
# => ╰────
let x: number = 1
# ok, no error
mut x: number = 1; $x = 2
# => Error: nu::parser::operator_incompatible_types
# =>
# => × Types 'number' and 'int' are not compatible for the '=' operator.
# => ╭─[source:1:20]
# => 1 │ mut x: number = 1; $x = 2
# => · ─┬ ┬ ┬
# => · │ │ ╰── int
# => · │ ╰── does not operate between 'number' and 'int'
# => · ╰── number
# => ╰────
```
After:
```nushell
let x: glob = ""
# ok, no error (same as before)
mut x: glob = ""; $x = ""
# ok, no error
let x: number = 1
# ok, no error (same as before)
mut x: number = 1; $x = 2
# ok, no error
```
- Properly type check compound operations. First checks if the operation
(eg. `+` for `+=`) type checks successfully, and then checks if the
assignment type checks successfully (also using `type_compatible`)
- This fixes some issues where the "long version" of a compound
assignment operator would error, but the compound assignment operator
itself would not
Before:
```nushell
mut x = 1; $x = $x / 2
# => Error: nu::parser::operator_incompatible_types
# =>
# => × Types 'int' and 'float' are not compatible for the '=' operator.
# => ╭─[entry #15:1:12]
# => 1 │ mut x = 1; $x = $x / 2
# => · ─┬ ┬ ───┬──
# => · │ │ ╰── float
# => · │ ╰── does not operate between 'int' and 'float'
# => · ╰── int
# => ╰────
mut x = 1; $x /= 2
# uh oh, no error...
mut x = (date now); $x = $x - 2019-05-10
# => Error: nu::parser::operator_incompatible_types
# =>
# => × Types 'datetime' and 'duration' are not compatible for the '=' operator.
# => ╭─[entry #1:1:21]
# => 1 │ mut x = (date now); $x = $x - 2019-05-10
# => · ─┬ ┬ ───────┬───────
# => · │ │ ╰── duration
# => · │ ╰── does not operate between 'datetime' and 'duration'
# => · ╰── datetime
# => ╰────
mut x = (date now); $x -= 2019-05-10
# uh oh, no error... (the result of this is a duration, not a datetime)
```
After:
```nushell
mut x = 1; $x = $x / 2
# => Error: nu::parser::operator_incompatible_types
# =>
# => × Types 'int' and 'float' are not compatible for the '=' operator.
# => ╭─[entry #5:1:12]
# => 1 │ mut x = 1; $x = $x / 2
# => · ─┬ ┬ ───┬──
# => · │ │ ╰── float
# => · │ ╰── does not operate between 'int' and 'float'
# => · ╰── int
# => ╰────
mut x = (date now); $x -= 2019-05-10
# => Error: nu::parser::operator_incompatible_types
# =>
# => × Types 'datetime' and 'datetime' are not compatible for the '-=' operator.
# => ╭─[entry #11:1:21]
# => 1 │ mut x = (date now); $x -= 2019-05-10
# => · ─┬ ─┬ ─────┬────
# => · │ │ ╰── datetime
# => · │ ╰── does not operate between 'datetime' and 'datetime'
# => · ╰── datetime
# => ╰────
# => help: The result type of this operation is not compatible with the type of the variable.
```
This is technically a breaking change if you relied on the old behavior
(for example, there was a test that broke after this change because it
relied on `/=` improperly type checking)
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Mutable assignment operations now use the same type checking rules as
normal assignments
* For example, `$x = 123` now uses the same type checking rules as `let
x = 123` or `mut x = 123`
* Compound assignment operations now type check using the same rules as
the operation they use
* Assignment errors will also now highlight the invalid assignment
operator in red
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Adds some tests for the examples given above
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
N/A
# Description
find's help message for '--columns' claims incompatibility with
'--regex'. However, both a review of the code and a test shows that this
is not true, and the two flags are compatible.
This commit removes the incompatibility claim.
# User-Facing Changes
* Help message of '--columns' flag in 'find' command is changed
# Tests + Formatting
Tested using 'toolkit check pr'. The stdlib tests don't pass on my
system, but they didn't before this commit either.
# After Submitting
This command isn't mentioned in the main text, but is mentioned in the
command reference. Should I rerun the command reference generator for
the website? or is that done automatically before releases?
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
This is so the styling can be set and reset without resetting the color.
NB. I don't have any domain or language knowledge here so am trying to
stick with existing patterns but it might be good to find out why code
like `Style::new().bold().prefix()` was used instead of just the raw SGR
(Select Graphic Rendition) codes (eg. `"\x1b[1m"`)
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
This PR improves the `metadata set` command by returning a clear error
when both `--datasource-filepath` and `--datasource-ls` flags are used
together. These flags are meant to be mutually exclusive, and previously
this conflicting usage was silently ignored.
# User-Facing Changes
* Users will now see an error message if they use both
`--datasource-filepath` and `--datasource-ls` together in `metadata
set`.
# Tests + Formatting
* [x] Added test at
`crates/nu-command/tests/commands/debug/metadata_set.rs` to verify the
error behavior.
* [x] Ran `cargo fmt --all -- --check`
* [x] Ran `cargo clippy --workspace -- -D warnings -D
clippy::unwrap_used`
* [x] Ran `cargo test --workspace`
# After Submitting
N/A
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR changes the behavior of #16028 to allow enabling experimental
options even if they are marked as deprecated.
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# Description
I use `toolkit run` to test PRs or my own code. Passing experimental
options to it makes this nicer if you're trying to test that out.
# User-Facing Changes
You can pass `--experimental-options` to `toolkit run`.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
# Description
In #16028 I also added a test to check that identifiers are valid to
ensure that we have consistency there. But I only checked for
alphanumeric strings as identifiers. It doesn't allow underscores or
dashes. @Bahex used in his PR about #15682 a dash to separate words. So
expanded the test to allow that.
# User-Facing Changes
None.
# Tests + Formatting
The `assert_identifiers_are_valid` now allows dashes.
# After Submitting
The tests in #15682 should work then.
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.33.1 to
1.34.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/crate-ci/typos/releases">crate-ci/typos's
releases</a>.</em></p>
<blockquote>
<h2>v1.34.0</h2>
<h2>[1.34.0] - 2025-06-30</h2>
<h3>Features</h3>
<ul>
<li>Updated the dictionary with the <a
href="https://redirect.github.com/crate-ci/typos/issues/1309">June
2025</a> changes</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's
changelog</a>.</em></p>
<blockquote>
<h2>[1.34.0] - 2025-06-30</h2>
<h3>Features</h3>
<ul>
<li>Updated the dictionary with the <a
href="https://redirect.github.com/crate-ci/typos/issues/1309">June
2025</a> changes</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="392b78fe18"><code>392b78f</code></a>
chore: Release</li>
<li><a
href="34b60f1f88"><code>34b60f1</code></a>
chore: Release</li>
<li><a
href="8b9670a614"><code>8b9670a</code></a>
docs: Update changelog</li>
<li><a
href="a6e61180eb"><code>a6e6118</code></a>
Merge pull request <a
href="https://redirect.github.com/crate-ci/typos/issues/1332">#1332</a>
from epage/juune</li>
<li><a
href="92f481e38a"><code>92f481e</code></a>
feat(dict): June 2025 updates</li>
<li><a
href="fb1f645959"><code>fb1f645</code></a>
chore(deps): Update Rust Stable to v1.88 (<a
href="https://redirect.github.com/crate-ci/typos/issues/1330">#1330</a>)</li>
<li><a
href="ebc6aac34e"><code>ebc6aac</code></a>
Merge pull request <a
href="https://redirect.github.com/crate-ci/typos/issues/1327">#1327</a>
from not-my-profile/fix-typo-in-error</li>
<li><a
href="e359d71a7f"><code>e359d71</code></a>
fix(cli): Correct config field reference in error message</li>
<li><a
href="022bdbe8ce"><code>022bdbe</code></a>
chore(ci): Update from windows-2019</li>
<li><a
href="ed74f4ebbb"><code>ed74f4e</code></a>
chore(ci): Update from windows-2019</li>
<li>Additional commits viewable in <a
href="https://github.com/crate-ci/typos/compare/v1.33.1...v1.34.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Description
This PR makes the span of a pipeline accessible through `metadata`,
meaning it's possible to get the span of a pipeline without collecting
it.
Examples:
```nushell
ls | metadata
# => ╭────────┬────────────────────╮
# => │ │ ╭───────┬────────╮ │
# => │ span │ │ start │ 170218 │ │
# => │ │ │ end │ 170220 │ │
# => │ │ ╰───────┴────────╯ │
# => │ source │ ls │
# => ╰────────┴────────────────────╯
```
```nushell
ls | metadata access {|meta|
error make {msg: "error", label: {text: "here", span: $meta.span}}
}
# => Error: × error
# => ╭─[entry #7:1:1]
# => 1 │ ls | metadata access {|meta|
# => · ─┬
# => · ╰── here
# => 2 │ error make {msg: "error", label: {text: "here", span: $meta.span}}
# => ╰────
```
Here's an example that wouldn't be possible before, since you would have
to use `metadata $in` to get the span, collecting the (infinite) stream
```nushell
generate {|x=0| {out: 0, next: 0} } | metadata access {|meta|
# do whatever with stream
error make {msg: "error", label: {text: "here", span: $meta.span}}
}
# => Error: × error
# => ╭─[entry #16:1:1]
# => 1 │ generate {|x=0| {out: 0, next: 0} } | metadata access {|meta|
# => · ────┬───
# => · ╰── here
# => 2 │ # do whatever with stream
# => ╰────
```
I haven't done the tests or anything yet since I'm not sure how we feel
about having this as part of the normal metadata, rather than a new
command like `metadata span` or something. We could also have a
`metadata access` like functionality for that with an optional closure
argument potentially.
# User-Facing Changes
* The span of a pipeline is now available through `metadata` and
`metadata access` without collecting a stream.
# Tests + Formatting
TODO
# After Submitting
N/A
1.88.0 was released today, clippy now lints (machine-applicable)
against:
- format strings with empty braces that could be inlined
- easy win
- `manual_abs_diff`
- returning of a stored result of the last expression.
- this can be somewhat contentious but touched only a few places
# Description
Added `debug -v` in case the default parameter is a string so that it
will be not be printed literally:
- Before
```nu
--char: <string> (default: )
```
```nu
--char: <string> (default:
)
```
```nu
--char: <string> (default: abc)
```
- After
```nu
--char: <string> (default: " ")
```
```nu
--char: <string> (default: "\n")
```
```nu
--char: <string> (default: "abc")
```
Other types like `int` remain unaffected.
# User-Facing Changes
# Tests + Formatting
# After Submitting
- fixes#16011
# Description
`Display` implementation for `f64` omits the decimal part for round
numbers, and by using it we did the same.
This affected:
- conversions to delimited formats: `csv`, `tsv`
- textual formats: `html`, `md`, `text`
- pretty printed `json` (`--raw` was unaffected)
- how single float values are displayed in the REPL
> [!TIP]
> This PR fixes our existing json pretty printing implementation.
> We can likely switch to using serde_json's impl using its
PrettyFormatter which allows arbitrary indent strings.
# User-Facing Changes
- Round trips through `csv`, `tsv`, and `json` preserve the type of
round floats.
- It's always clear whether a number is an integer or a float in the
REPL
```nushell
4 / 2
# => 2 # before: is this an int or a float?
4 / 2
# => 2.0 # after: clearly a float
```
# Tests + Formatting
Adjusted tests for the new behavior.
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
There was no hint as to what datetime escape sequences are supported,
previously. Looked into the source code to figure this out, which is not
great ux hehehe
# User-Facing Changes
# Tests + Formatting
# After Submitting
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This simply updates the `which` dependency from 7.0.3 to 8.0.0, with no
code changes. See
https://github.com/harryfei/which-rs/releases/tag/8.0.0 for release
notes.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
N/A
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Tested with `cargo test --workspace` and `cargo run -- -c "use
toolkit.nu; toolkit test stdlib"`.
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
N/A
- fixes#14946
- related #15227
- > [When I run nushell with the hook, the hook itself works as
expected, correctly detects system theme and changes
$env.config.color_config. However, it seems that the change to
$env.config.color_config is not propagated outside the
hook](https://github.com/nushell/nushell/issues/15227#issuecomment-2695287318)
- > [But it suffers from the same problem - modifications made to the
$env.config variable are not visible outside of the hook (which I'm not
sure if is correct behavior or
bug).](https://github.com/nushell/nushell/issues/15227#issuecomment-2695741542)
- > [I also managed to get it working with def --env, but there was one
more issue, I had to change $env.config.hooks.pre_prompt = [{
switch_theme }] into $env.config.hooks.pre_execution = ([ switch_theme
])](https://github.com/nushell/nushell/issues/15227#issuecomment-2704537565)
(having to use a string hook rather than a closure)
- related #11082
> Might be possible solve or at least mitigate using a similar method
# Description
Recently realized that changes made to `$env.config` in closure hooks
don't take effect whereas string hooks don't have that problem.
After some investigation:
- Hooks' environment was not preserved prior to #5982 >
[2309601](2309601dd4/crates/nu-cli/src/repl.rs (L823-L840))
- `redirect_env` which properly updates the config state was implemented
afterwards in #6355 >
[ea8b0e8](ea8b0e8a1d/crates/nu-engine/src/eval.rs (L174-L190))
Simply using `nu_engine::eval::redirect_env` for the environment update
was enough to fix the issue.
# User-Facing Changes
Hooks can update `$env.config` and the configuration change will work as
expected.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
Adds formatting for code in backticks in `help` output. If it's possible
to highlight syntax (`nu-highlight` is available and there's no invalid
syntax) then it's highlighted. If the syntax is invalid or not an
internal command, then it's dimmed and italicized. like some of the
output from `std/help`. If `use_ansi_coloring` is `false`, then we leave
the backticks alone. Here's a couple examples:
(note on this one: usually we can highlight partial commands, like `get`
in the `select` help page which is invalid according to `nu-check` but
is still properly highlighted, however `where` is special cased and just
typing `where` with no row condition is highlighted with the garbage
style so `where` alone isn't highlighted here)
here's the `where` page with `$env.config.use_ansi_coloring = false`:
Technically, some syntax is valid but isn't really "Nushell code". For
example, the `select` help page has a line that says "Select just the
\`name\` column". If you just type `name` in the REPL, Nushell treats it
as an external command, but for the purposes of highlighted we actually
want this to fall back to the generic dimmed/italic style. This is
accomplished by temporarily setting the `shape_external` and
`shape_externalarg` color config to the generic/fallback style, and then
restoring the color config after highlighting. This is a bit hack-ish
but it seems to work pretty well.
# User-Facing Changes
- `help` command now supports code backtick formatting. Code will be
highlighted using `nu-highlight` if possible, otherwise it will fall
back to a generic format.
- Adds `--reject-garbage` flag to `nu-highlight` which will return an
error on invalid syntax (which would otherwise be highlighted with
`$env.config.color_config.shape_garbage`)
# Tests + Formatting
Added tests for the regex. I don't think tests for the actual
highlighting are very necessary since the failure mode is graceful and
it would be difficult to meaningfully test.
# After Submitting
N/A
---------
Co-authored-by: Piepmatz <git+github@cptpiepmatz.de>
It was brought up in the Discord that `default { open -r foo.txt }`
results in a string instead of streaming output. This changes `default`
such that closures now stream when given simple input.
# Description
If the value isn't expected to be cached, `default` just runs the
closure without caching the value, which allows its output to be
streamed
# User-Facing Changes
# Tests + Formatting
👍
# After Submitting
Closes: https://github.com/nushell/nushell/issues/13127
# Description
This PR updates the behaviour of `start` in the following ways:
Instead of joining the path with CWD, we expand the path.
Behaviour on `origin/main`:
```
nushell> ls ~/nushell-test
test.txt
nushell> start ~/nushell-test/test.txt
Error: × Cannot find file or URL: ~/nushell-test/test.txt
...
help: Ensure the path or URL is correct and try again.
```
Behaviour in this PR:
```
nushell> ls ~/nushell-test
test.txt
nushell> start ~/nushell-test/test.txt
<opens text editor>
```
# User-Facing Changes
`start` now treats the input path differently. This is a breaking
change, I believe. Although I'm not sure how breaking it would be in the
perspective of the user.
# Tests + Formatting
I've manually tested this. The test suite for `start` is broken. And
even if I fix it, I'm not sure how to test it.
I'll need to override the default command list for `start` in the
sandbox for testing.
# After Submitting
I don't think the documentation needs to be updated.
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR adds the `only` command to `std-rfc/iter`, which is a command I
wrote a while ago that I've found so useful that I think it could have a
place in the standard library. It acts similarly to `get 0`, but ensures
that the value actually exists, and there aren't additional values. I
find this most useful when chained with `where`, when you want to be
certain that no additional elements are accidentally selected when you
only mean to get a single element.
I'll copy the help page here for additional explanation:
> Get the only element of a list or table, ensuring it exists and there
are no extra elements.
>
> Similar to `first` with no arguments, but errors if there are no
additional
> items when there should only be one item. This can help avoid issues
when more
> than one row than expected matches some criteria.
>
> This command is useful when chained with `where` to ensure that only
one row
> meets the given condition.
>
> If a cell path is provided as an argument, it will be accessed after
the first
> element. For example, `only foo` is roughly equivalent to `get 0.foo`,
with
> the guarantee that there are no additional elements.
>
> Note that this command currently collects streams.
> Examples:
>
> Get the only item in a list, ensuring it exists and there's no
additional items
> ```nushell
> [5] | only
> # => 5
> ```
>
> Get the `name` column of the only row in a table
> ```nushell
> [{name: foo, id: 5}] | only name
> # => foo
> ```
>
> Get the modification time of the file named foo.txt
> ```nushell
> ls | where name == "foo.txt" | only modified
> ```
Here's some additional examples showing the errors:
Most of the time I chain this with a simple `where`, but here's a couple
other real world examples of how I've used this:
[With `parse`, which outputs a
table](https://git.ikl.sh/132ikl/dotfiles/src/branch/main/.scripts/manage-nu#L53):
```nushell
let commit = $selection | parse "{start}.g{commit}-{end}" | only commit
```
[Ensuring that only one row in a table has a name that ends with a
certain
suffix](https://git.ikl.sh/132ikl/dotfiles/src/branch/main/.scripts/btconnect):
```nushell
$devices | where ($chosen_name ends-with $it.name) | only
```
Unfortunately to get these nice errors I had to collect the stream (and
I think the errors are more useful for this). This should be to be
mitigated with (something like) #16014.
Putting this in `std/iter` might be pushing it, but it seems *just*
close enough that I can't really justify putting it in a different/new
module.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Adds the `only` command to `std-rfc/iter`, which can be used to ensure
that a table or list only has a single element.
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Added a few tests for `only` including error cases
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
N/A
---------
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
# Description
I wanted to know if `version` is a const command and thought that it
would be in the "This command" section but it wasn't, so I added it.
```
→ help version
Display Nu version, and its build configuration.
Category: core
This command:
Creates scope | ❌
Is built-in | ✅
Is const | ✅
Is a subcommand | ❌
Is a part of a plugin | ❌
Is a custom command | ❌
Is a keyword | ❌
```
# Description
Adding to #15962, I have realized that there are windows gui programs
like `prismlauncher` or `firefox` that do accept the `--help` flag but
won't output on the terminal unless `collect`ed, so now it collects the
output on windows.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
## ✅ Improve `drop nth` command to support spreadable arguments
### Summary
This PR updates the `drop nth` command to support **spreadable
arguments** in a way consistent with other commands like `which`,
enabling:
```nu
[1 2 3 4 5] | drop nth 0 2 4
```
### What's Changed
* **Previously**: only a single index or a single range was accepted as
the first argument, with rest arguments ignored for ranges.
* **Now**: the command accepts any combination of:
* Integers: to drop individual rows
* Ranges: to drop slices of rows
* Unbounded ranges: like `3..`, to drop from index onward
Example:
```nu
[one two three four five six] | drop nth 0 2 4..5
# drops "one", "three", "five", and "six"
```
### Test
Manual Test:
### Notes
As per feedback:
* We **only collect the list of indices** to drop, not the input stream.
* Unbounded ranges are handled by terminating the stream early.
Let me know if you'd like further changes
---------
Co-authored-by: Kumar Ujjawal <kumar.ujjawal@greenpista.com>
Co-authored-by: Kumar Ujjawal <kumarujjawal@Kumars-MacBook-Air.local>
Fixes the default behavior of #15790
# Description
As for the mentioned carapace version: `cat ~"/Downloads/Obsidian
Vault/"`, the problem lies in the unexpanded home directory `~`. Either
we encourage users to manually expand that in
`$env.config.completions.external.completer` or open an issue on the
carapace project.
# User-Facing Changes
bug fix
# Tests + Formatting
Adjusted
# After Submitting
# Description
Add 'double' table mode, that is similar to `compact_double` but with
left and right border lines. This is similar to how there exist both
`single` and `compact`, but there is no `double` to compliment
`compact_double`. Printing `[ { a: 1, b: 11 }, { a: 2, b:12 } ]` looks
like this:
```
╔═══╦═══╦════╗
║ # ║ a ║ b ║
╠═══╬═══╬════╣
║ 0 ║ 1 ║ 11 ║
║ 1 ║ 2 ║ 12 ║
╚═══╩═══╩════╝
```
The implementation is mostly a one-to-one of #15672 and #15681.
# User-Facing Changes
New value `double` to set as `$env.config.table.mode`.
# Tests + Formatting
Tests are added following the example of adding 'single' mode.
# After Submitting
# Description
fixes#16010
When `$env.LS_COLORS = 'fi=0' and `$env.config.color_config.string =
'red'` were set, regular files without file extensions would be colored
red. Now they're colored based on the LS_COLORS definition which, in
this case, means use default colors.
This is done by checking if a style was applied from ls_colors and if
none was applied, create a default nu_ansi_term style with
'Color::Default' for foreground and background.
### Before
### After
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
---------
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
# Description
Use hashset for existence checking.
Still needs a vector collection to keep the column order for tables.
# User-Facing Changes
Should be None
# Description
I have just discovered the `std/help` command and that it can use `man`
or other programs for externals. Coming from windows, I don't have `man`
so what I want is just to run `external_program --help` in most cases.
This pr adds that option, if you set `$env.NU_HELPER = "--help"`, it
will run the command you passed with `--help` added as the last
argument.
# User-Facing Changes
None
# Tests + Formatting
# After Submitting
Refs #15992
Refs #14457
# Description
This PR introduces a new switch for `query xml`, `--namespaces`,
and thus allows people to use namespace prefixes in the XPath query
to query namespaced XML.
Example:
```nushell
r#'
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:dc="http://purl.org/dc/elements/1.1/"
<dc:title>Black-breasted buzzard_AEB_IMG_7158</dc:title>
</rdf:Description>
</rdf:RDF>
'# | query xml --namespaces {dublincore: "http://purl.org/dc/elements/1.1/"} "//dublincore:title/text()"
```
# User-Facing Changes
New switch added to `query xml`: `query xml --namespaces {....}`
# Tests + Formatting
Pass.
# After Submitting
IIRC the commands docs on the website are automatically generated, so
nothing to do here.
# Description
This PR fixes an oversight where the record key value was not being
colored as the color_config.header color when used with the `table`
command in some circumstances. It respected it with `table -e` but just
not `table`.
### Before
### After
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
- related #15972
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
In #15972 I was very eager removing fowarded features from `nu` to
`nu-cmd-lang`. By accident I also removed `nu-cmd-lang/plugin` too. This
removed `installed_plugins` from `version`. By adding the feature again,
it works again.
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Addresses #15997
Adds a `--backtrack` or `-b` named flag to the `parse` command. Allows a
user to specify a max backtrack limit for fancy-regex other than the
default 1,000,000 limit.
Uses a RegexBuilder to add the manual config.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Adds a new named flag `backtrack` to the `parse` command. The flag is
optional and defaults to 1,000,000.
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Added an example test to the parse command using `--backtrack 1500000`.
Bumps [shadow-rs](https://github.com/baoyachi/shadow-rs) from 1.1.1 to
1.2.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/baoyachi/shadow-rs/releases">shadow-rs's
releases</a>.</em></p>
<blockquote>
<h2>v1.2.0</h2>
<h2>What's Changed</h2>
<ul>
<li>add cargo_metadata crate unit test by <a
href="https://github.com/baoyachi"><code>@baoyachi</code></a> in <a
href="https://redirect.github.com/baoyachi/shadow-rs/pull/231">baoyachi/shadow-rs#231</a></li>
<li>Update cargo_metadata requirement from 0.19.1 to 0.20.0 by <a
href="https://github.com/dependabot"><code>@dependabot</code></a> in <a
href="https://redirect.github.com/baoyachi/shadow-rs/pull/229">baoyachi/shadow-rs#229</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/baoyachi/shadow-rs/compare/v1.1.1...v1.2.0">https://github.com/baoyachi/shadow-rs/compare/v1.1.1...v1.2.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="f0d180ac92"><code>f0d180a</code></a>
Update Cargo.toml</li>
<li><a
href="d106a172ad"><code>d106a17</code></a>
Merge pull request <a
href="https://redirect.github.com/baoyachi/shadow-rs/issues/229">#229</a>
from baoyachi/dependabot/cargo/cargo_metadata-0.20.0</li>
<li><a
href="7861af1dd0"><code>7861af1</code></a>
Merge branch 'master' into dependabot/cargo/cargo_metadata-0.20.0</li>
<li><a
href="ab73c01cd1"><code>ab73c01</code></a>
Merge pull request <a
href="https://redirect.github.com/baoyachi/shadow-rs/issues/231">#231</a>
from baoyachi/cargo_metadata</li>
<li><a
href="ff1a1dcf27"><code>ff1a1dc</code></a>
fix cargo clippy check</li>
<li><a
href="f59bceaf92"><code>f59bcea</code></a>
add cargo_metadata crate unit test</li>
<li><a
href="5c5b556400"><code>5c5b556</code></a>
Update cargo_metadata requirement from 0.19.1 to 0.20.0</li>
<li>See full diff in <a
href="https://github.com/baoyachi/shadow-rs/compare/v1.1.1...v1.2.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Inspired by https://github.com/nushell/nushell/pull/15979 a small Github
actions bot that detects when you make a change to the `nu-protocol`
bits of the config and reminds to consider making a change to the
Nushell version in `doc_config.nu` as well.
# Description
Instead of converting nested structures into strings and
pattern-matching the strings, the `find` command will recursively search
the nested structures for matches.
- fixes#15618
# User-Facing Changes
Text in nested structures will now be highlighted as well.
Error values will always passed on instead of testing them against the
search term
There will be slight changes in match behavior, such as characters that
are part of the string representations of data structures no longer
matching all nested data structures.
- fixes#15975
# Description
This changes the `config nu --doc` output for OSC 7 and 9;9 to represent
better what happens on Windows machines.
This is the current behavior internally:
5be8717fe8/crates/nu-protocol/src/config/shell_integration.rs (L18-L27)
And with this PR the `config nu --doc` better reflects that behavior,
thanks to @fdncred for that idea.
# User-Facing Changes
None
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
---------
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
Follow-up to #15877. That PR was created before 0.105, but merged after
it was released. This PR adjusts the deprecation window from
0.105.0-0.107.0 to 0.106.0-0.108.0
# Description
Currently, `help --find` uses it's own code for looking for the keyword
in a string and highlighting it. This code duplicates a lot of the logic
found in the code of `find`.
This commit re-uses the code of `find` in `help` commands instead.
# User-Facing Changes
This should not affect the behavior of `help`.
# Description
Commands in `std/log` assume the `export-env` has been run and the
relevant environment variables are set.
However, when modules/libraries import `std/log` without defining their
own `export-env` block to run `std/log`'s, logging commands will fail at
runtime.
While it's on the author of the modules to include `export-env { use
std/log [] }` in their modules, this is a very simple issue to solve and
would make the user experience smoother.
# User-Facing Changes
`std/log` work without problem when their env vars are not set.
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
Co-authored-by: 132ikl <132@ikl.sh>
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
1. Upgrade Nushell to 0.105.1 for release and nightly workflow
2. Use `hustcer/setup-nu` Action for `windows-11-arm` runner to simplify
the workflow
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
None
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Looks fine here:
https://github.com/hustcer/nushell/actions/runs/15657383788/job/44110173668#step:7:1357
- closes#15967
# Description
In 0.105 we introduced the feature `rustls-tls` which is enabled by
default and uses `rustls` instead of `openssl` on linux machines. Since
both `native-tls` and `rustls-tls` cannot be enabled at the same did
this break the `--all-features` flag. To provide an easy alternative, I
introduced the `full` feature here.
# User-Facing Changes
Instead of `cargo install nu --all-features`, you now can do `cargo
install nu --features full`.
# Tests + Formatting
No new tests, this is just a feature collection.
# Description
This PR adds a new `state` key to the output of `gstat` that shows the
current repo state state. Like "Clean", "Merge", "Rebase", etc. The full
list of possible values can be seen
[here](https://docs.rs/git2/latest/git2/enum.RepositoryState.html).
This information is somewhat useful when shown in prompt. Not often
needed, but sometimes really useful.
# User-Facing Changes
New key added to `gstat` output. I don't think it should cause issues to
`gstat` users.
# Tests + Formatting
I couldn't find any tests for `nu_plugin_gstat`.
# After Submitting
I couldn't find any documentation about the output of `gstat`, so I
don't think there is anything to be done here either.
Hello, this PR resolves the second request of the issue
https://github.com/nushell/nushell/issues/10957, which involves using a
default verb based on the request. If a URL is provided, the command
will default to GET, and if data is provided, it will default to POST.
This means that the following pairs of commands are equivalent:
```
http --content-type application/json http://localhost:8000 {a:1}
http post --content-type application/json http://localhost:8000 {a:1}
```
```
http http://localhost:8000 "username"
http post http://localhost:8000 "username"
```
```
http http://localhost:8000
http get http://localhost:8000
```
The `http` command now accepts all flags of the `post` and `get`
commands. It will still display the help message if no subcommand is
provided, and the description has been updated accordingly. The logic in
the `http` command is minimal to delegate error management
responsibilities to the specific `run_get` and `run_post` functions.
# Description
Based on some testing in
[Discord](https://discord.com/channels/601130461678272522/1349836000804995196/1353138803640111135)
we were able to find that `insert` and `delete` happening at the same
time caused problems in the `stor` command. So, I added `conn.is_busy()`
with a sleep to try and avoid that problem.
/cc @NotTheDr01ds @132ikl
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
I've noticed that unlike everything else in nushell the output of `ansi
--list` has a column named `short name` instead of `short_name`, so I
changed it. While I was at it, I also added a shortname `rst` to `reset`
since it is often used.
# User-Facing Changes
Changed the column name of `ansi --list` from `short name` to
`short_name`
# Description
I have added a `--no-prefix` flag to the `format number` command to not
include the `0b`, `0x` and `0o` prefixes in the output. Also, I've
changed the order in which the formats are displayed to one I thinks
makes it easier to read, with the upper and lower alternatives next to
each other.
# User-Facing Changes
The formatting of floats previously did not include prefixes while
integers did. Now prefixes are on by default for both, while including
the new flag removes them. Changing the order of the record shouldn't
have any effect on previous code.
# Tests + Formatting
I have added an additional example that test this behavior.
# After Submitting
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
2025-06-13 16:13:26 -05:00
503 changed files with 8856 additions and 4272 deletions
if this PR closes one or more issues, you can automatically link the PR with
them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g.
you can also mention related issues, PRs or discussions!
Use the following space to include the motivation and any technical details behind this PR.
-->
# Description
## Release notes summary - What our users need to know
<!--
Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes.
Description of your pull request goes here.**Provide examples and/or screenshots** if your changes affect the user experience.
This section will be included as part of our release notes. See the contributing guide for more details.
If you're not confident about this, a core team member would be glad to help!
-->
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. -->
# 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 -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style
-`cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
-`cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
## Tasks after submitting
<!-- Remove any tasks which aren't relevant for your PR, or add your own -->
- [ ] Update the [documentation](https://github.com/nushell/nushell.github.io)
Hey, just a bot checking in! You edited files related to the configuration.
If you changed any of the default values or added a new config option, don't forget to update the [`doc_config.nu`](https://github.com/nushell/nushell/blob/main/crates/nu-utils/src/default_files/doc_config.nu) which documents the options for our users including the defaults provided by the Rust implementation.
If you didn't make a change here, you can just ignore me.
@ -20,6 +21,51 @@ More resources can be found in the nascent [developer documentation](devdocs/REA
- [Platform support policy](devdocs/PLATFORM_SUPPORT.md)
- [Our Rust style](devdocs/rust_style.md)
## Tips for submitting PRs
Thank you for improving Nushell! We are always glad to see contributions, and we are absolutely willing to talk through the design or implementation of your PR. Come talk with us in [Discord](https://discordapp.com/invite/NtAbbGn), or create a GitHub discussion or draft PR and we can help you work out the details from there.
**Please talk to the core team before making major changes!** See the [proposing design changes](#proposing-design-changes) for more details.
### Release notes section
In our PR template, we have a "Release notes summary" section which will be included in our release notes for our blog.
This section should include all information about your change which is relevant to a user of Nushell. You should try to keep it **brief and simple to understand**, and focus on the ways your change directly impacts the user experience. We highly encourage adding examples and, when relevant, screenshots in this section.
Please make sure to consider both the *intended changes*, such as additions or deliberate breaking changes **and** possible *side effects* that might change how users interact with a command or feature. It's important to think carefully about the ways that your PR might affect any aspect of the user experience, and to document these changes even if they seem minor or aren't directly related to the main purpose of the PR.
This section might not be relevant for all PRs. If your PR is a work in progress, feel free to write "WIP"/"TODO"/etc in this section. You can also write "N/A" if this is a technical change which doesn't impact the user experience.
If you're not sure what to put here, or need some help, **a core team member would be glad to help you out**. We may also makes some tweaks to your release notes section. Please don't take it personally, we just want to make sure our release notes are polished and easy to understand. Once the release notes section is ready, we'll add the (TODO label name) label to indicate that the release notes section is ready to be included in the actual release notes.
### Tests and formatting checks
Our CI system automatically checks formatting and runs our tests. If you're running into an issue, or just want to make sure everything is ready to go before creating your PR, you can run the checks yourself:
```nushell
use toolkit.nu # or use an `env_change` hook to activate it automatically
toolkit check pr
```
Furthermore, you can also runs these checks individually with the subcommands of `toolkit`, or run the underlying commands yourself:
-`cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes)
-`cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style
-`cargo test --workspace` to check that all tests pass (on Windows make sure to enable [developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
-`cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library
If the checks are passing on your local system, but CI just won't pass, feel free to ask for help from the core team.
### Linking and mentioning issues
If your PR closes one or more issues, you can automatically link the PR with them by using one of the [linking keywords](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword):
- This PR should close #xxxx
- Fixes #xxxx
You can also mention related issues, PRs or discussions!
## Proposing design changes
First of all, before diving into the code, if you want to create a new feature, change something significantly, and especially if the change is user-facing, it is a good practice to first get an approval from the core team before starting to work on it.
As a shell and programming language Nushell provides you with great powers and the potential to do dangerous things to your computer and data. Whenever there is a risk that a malicious actor can abuse a bug or a violation of documented behavior/assumptions in Nushell to harm you this is a *security* risk.
As a shell and programming language Nushell provides you with great powers and the potential to do dangerous things to your computer and data. Whenever there is a risk that a malicious actor can abuse a bug or a violation of documented behavior/assumptions in Nushell to harm you this is a *security* risk.
We want to fix those issues without exposing our users to unnecessary risk. Thus we want to explain our security policy.
Additional issues may be part of *safety* where the behavior of Nushell as designed and implemented can cause unintended harm or a bug causes damage without the involvement of a third party.
@ -11,7 +11,7 @@ Only if you provide a strong reasoning and the necessary resources, will we cons
## Reporting a Vulnerability
If you suspect that a bug or behavior of Nushell can affect security or may be potentially exploitable, please report the issue to us in private.
If you suspect that a bug or behavior of Nushell can affect security or may be potentially exploitable, please report the issue to us in private.
Either reach out to the core team on [our Discord server](https://discord.gg/NtAbbGn) to arrange a private channel or use the [GitHub vulnerability reporting form](https://github.com/nushell/nushell/security/advisories/new).
err_message: "Debounce duration is invalid".to_string(),
span: val.span,
}),
},
(Some(v),None)=>Ok(v.item),
}
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
