# 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
