- 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
353 changed files with 5329 additions and 2548 deletions
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.
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.
