<!--
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.
-->
Tweaks the error style for I/O errors introduced #14927. Moves the
additional context to below the text that says "I/O error", and always
shows the error kind in the label.
Additional context|Before PR|After PR
:-:|:-:|:-:
yes|
|
no|
|
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
N/A, as this is a follow-up to #14927 which has not been included in a
release
# 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
> ```
-->
N/A
# 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: Piepmatz <git+github@cptpiepmatz.de>
# Description
Adds pipeline metadata to the `to html` command output (hardcoded to
`text/html; charset=utf-8`)
# User-Facing Changes
Pipeline metadata is now included with the `to html` command output.
# Description
This reverts back to serde_yaml from serde_yml.
Closes https://github.com/nushell/nushell/issues/14934
Reopen https://github.com/nushell/nushell/pull/14630
# 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.
-->
This PR makes two changes related to [run-time pipeline input type
checking](https://github.com/nushell/nushell/pull/14741):
1. The check which bypasses type checking for commands with only
`Type::Nothing` input types has been expanded to work with commands with
multiple `Type::Nothing` inputs for different outputs. For example,
`ast` has three input/output type pairs, but all of the inputs are
`Type::Nothing`:
```
╭───┬─────────┬────────╮
│ # │ input │ output │
├───┼─────────┼────────┤
│ 0 │ nothing │ table │
│ 1 │ nothing │ record │
│ 2 │ nothing │ string │
╰───┴─────────┴────────╯
```
Before this PR, passing a value (which would otherwise be ignored) to
`ast` caused a run-time type error:
```
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #1:1:6]
1 │ echo 123 | ast -j -f "hi"
· ─┬─ ─┬─
· │ ╰── only nothing, nothing, and nothing input data is supported
· ╰── input type: int
╰────
```
After this PR, no error is raised.
This doesn't really matter for `ast` (the only other built-in command
with a similar input/output type signature is `cal`), but it's more
logically consistent.
2. Bypasses input type-checking (parse-time ***and*** run-time) for some
(not all, see below) commands which have both a `Type::Nothing` input
and some other non-nothing `Type` input. This is accomplished by adding
a `Type::Any` input with the same output as the corresponding
`Type::Nothing` input/output pair.
This is necessary because some commands are intended to operate on an
argument with empty pipeline input, or operate on an empty pipeline
input with no argument. This causes issues when a value is implicitly
passed to one of these commands. I [discovered this
issue](https://discord.com/channels/601130461678272522/615962413203718156/1329945784346611712)
when working with an example where the `open` command is used in
`sort-by` closure:
```nushell
ls | sort-by { open -r $in.name | lines | length }
```
Before this PR (but after the run-time input type checking PR), this
error is raised:
```
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #1:1:1]
1 │ ls | sort-by { open -r $in.name | lines | length }
· ─┬ ──┬─
· │ ╰── only nothing and string input data is supported
· ╰── input type: record<name: string, type: string, size: filesize, modified: date>
╰────
```
While this error is technically correct, we don't actually want to
return an error here since `open` ignores its pipeline input when an
argument is passed. This would be a parse-time error as well if the
parser was able to infer that the closure input type was a record, but
our type inference isn't that robust currently, so this technically
incorrect form snuck by type checking until #14741.
However, there are some commands with the same kind of type signature
where this behavior is actually desirable. This means we can't just
bypass type-checking for any command with a `Type::Nothing` input. These
commands operate on true `null` values, rather than ignoring their
input. For example, `length` returns `0` when passed a `null` value.
It's correct, and even desirable, to throw a run-time error when
`length` is passed an unexpected type. For example, a string, which
should instead be measured with `str length`:
```nushell
["hello" "world"] | sort-by { length }
# => Error: nu:🐚:only_supports_this_input_type
# =>
# => × Input type not supported.
# => ╭─[entry #32:1:10]
# => 1 │ ["hello" "world"] | sort-by { length }
# => · ───┬─── ───┬──
# => · │ ╰── only list<any>, binary, and nothing input data is supported
# => · ╰── input type: string
# => ╰────
```
We need a more robust way for commands to express how they handle the
`Type::Nothing` input case. I think a possible solution here is to allow
commands to express that they operate on `PipelineData::Empty`, rather
than `Value::Nothing`. Then, a command like `open` could have an empty
pipeline input type rather than a `Type::Nothing`, and the parse-time
and run-time pipeline input type checks know that `open` will safely
ignore an incorrectly typed input.
That being said, we have a release coming up and the above solution
might take a while to implement, so while unfortunate, bypassing input
type-checking for these problematic commands serves as a workaround to
avoid breaking changes in the release until a more robust solution is
implemented.
This PR bypasses input type-checking for the following commands:
* `load-env`: can take record of envvars as input or argument
* `nu-check`: checks input string or filename argument
* `open`: can take filename as input or argument
* `polars when`: can be used with input, or can be chained with another
`polars when`
* `stor insert`: data record can be passed as input or argument
* `stor update`: data record can be passed as input or argument
* `format date`: `--list` ignores input value
* `into datetime`: `--list` ignores input value (also added a
`Type::Nothing` input which was missing from this command)
These commands have a similar input/output signature to the above
commands, but are working as intended:
* `cd`: The input/output signature was actually incorrect, `cd` always
ignores its input. I fixed this in this PR.
* `generate`
* `get`
* `history import`
* `interleave`
* `into bool`
* `length`
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
As a temporary workaround, pipeline input type-checking for the
following commands has been bypassed to avoid undesirable run-time input
type checking errors which were previously not caught at parse-time:
* `open`
* `load-env`
* `format date`
* `into datetime`
* `nu-check`
* `stor insert`
* `stor update`
* `polars when`
# 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
> ```
-->
CI became green in the time it took me to type the description 😄
# 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
I'm on rust toolchain 1.8.4, and I can see clippy warnings that can't be
caught by the ci workflow, primarily related to lifetime params.
I think it doesn't hurt to fix those in advance.
# User-Facing Changes
# Tests + Formatting
# After Submitting
# Description
This PR closes#14956, only one known issue on that list remains.
# User-Facing Changes
# Tests + Formatting
new cases added
# After Submitting
<!--
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.
-->
When using `find`, we insert ansi code.
This is great for visual but it make comparison a tedious task.
For exemple
```nu
> ([{a: 1 b: 1}] | find 1 | get 0 | get a) == 1
# false
```
The documentation recommand using the `ansi strip` command but you then
lose your typing converting it to a string.
```nu
> [{a: 1 b: 1}] | find 1 | get 0 | get a | ansi strip | describe
# string
```
And this makes me very sad 😢 .
The idea here is to have a simple option to keep the usage of `find`
without the ansi marking.
```nu
> ([{a: 1 b: 1}] | find --raw 1 | get 0 | get a) == 1
# true
```
Tbh I think we could also do a fix on the parser to really escape the
ansi makers but this sounded like way more work so I would like your
opinion on this before working on it.
Also note that this is my first time writting rust and trying to
contribute to nushell so if you see any weird shenanigans be sure to
tell me !
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
A new flag for find
# 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
> ```
-->
For testing I updated all the previous `find` test to also run them with
this new flag just to be sure that we didn't lose any other
functionalities
# 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: Tangui <mael.nicolas@clever-cloud.com>
- fixes#14769
# Description
## Bugs
- `str substring 0..<0`
When passed a range containing no elements, for non-zero cases `str
substring` behaves correctly:
```nushell
("hello world" | str substring 1..<1) == ""
# => true
```
but if the range is `0..<0`, it returns the whole string instead
```nushell
"hello world" | str substring 0..<0
# => hello world
```
- `[0 1 2] | range 0..<0`
Similar behavior to `str substring`
- `str index-of`
- off-by-one on end bounds
- underflow on negative start bounds
- `bytes at` has inconsistent behavior, works correctly when the size is
known, returns one byte less when it's not known (streaming)
This can be demonstrated by comparing the outputs of following snippets
```nushell
"hello world" | into binary | bytes at ..<5 | decode
# => hello
"hello world" | into binary | chunks 1 | bytes collect | bytes at ..<5 |
decode
# => hell
```
- `bytes at` panics on decreasing (`5..3`) ranges if the input size is
known. Does not panic with streaming input.
## Changes
- implement `FromValue` for `IntRange`, as it is very common to use
integer ranges as arguments
- `IntRange::absolute_start` can now point one-past-end
- `IntRange::absolute_end` converts relative `Included` bounds to
absolute `Excluded` bounds
- `IntRange::absolute_bounds` is a convenience method that calls the
other `absolute_*` methods and transforms reverse ranges to empty at
`start` (`5..3` => `5..<5`)
- refactored `str substring` tests to allow empty exclusive range tests
- fix the `0..<0` case for `str substring` and `str index-of`
- `IntRange::distance` never returns `Included(0)`
As a general rule `Included(n) == Excluded(n + 1)`.
This makes returning `Included(0)` bug prone as users of the function
will likely rely on this general rule and cause bugs.
- `ByteStream::slice` no longer has an off-by-one on inputs without a
known size. This affected `bytes at`.
- `bytes at` no longer panics on reverse ranges
- `bytes at` is now consistent between streaming and non streaming
inputs.
# User-Facing Changes
There should be no noticeable changes other than the bugfix.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# 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 returns error values while checking pipeline input types and
positional argument types. This should help return non-nested errors
earlier and prevent confusing errors.
The positional argument change is directly related to an example given
on Discord. Before this PR, this is the error shown:
```
Error: nu:🐚:cant_convert
× Can't convert to record.
╭─[/home/rose/tmp/script.nu:23:5]
22 │ let entry = $in
23 │ ╭─▶ {
24 │ │ name: $entry,
25 │ │ details: {
26 │ │ context: $context
27 │ │ }
28 │ ├─▶ }
· ╰──── can't convert error to record
29 │ }
╰────
```
After this PR, this is the error shown:
```
Error: nu:🐚:eval_block_with_input
× Eval block failed with pipeline input
╭─[/home/rose/tmp/script.nu:23:5]
22 │ let entry = $in
23 │ ╭─▶ {
24 │ │ name: $entry,
25 │ │ details: {
26 │ │ context: $context
27 │ │ }
28 │ ├─▶ }
· ╰──── source value
29 │ }
╰────
Error: nu:🐚:type_mismatch
× Type mismatch.
╭─[/home/rose/tmp/much.nu:3:38]
2 │ $in | each { |elem|
3 │ print $elem.details.context.yaml.0
· ┬
· ╰── Can't access record values with a row index. Try specifying a column name instead
4 │ } | each { |elem|
╰────
```
I'm not certain if the pipeline input error check actually can ever be
triggered, but it seems to be a good defensive error handling strategy
regardless. My addition of the `Value::Error` case in the first place
would suggest it can be, but after looking at it more closely the error
that caused me to add the case in the first place was actually unrelated
to input typechecking.
Additionally, this PR does not affect the handling of nested errors, so
something like:
```nushell
try { ... } catch {|e| $e | reject raw | to nuon }
```
works the same before and after this PR.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Errors values detected as arguments to commands or as pipeline input to
commands are immediately thrown, rather than passed to the command.
# 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.
-->
N/A
# Description
This is a follow up for pr:
https://github.com/nushell/nushell/pull/13873
In that pr, I left 2 TODOs about tests, this pr is going to resolve
them.
# User-Facing Changes
NaN
# Tests + Formatting
Added 2 tests
# Description
Closes#14957
Allows for moving columns to the start and end of a table/record. Adds
additional tests for the new flags and refactors the already existing
tests to assert on a vec of columns rather then asserting one by one.
# User-Facing Changes
Addition: New `--first` and `--last` flags for `move` which allow you to
move columns to the start or end without the need to specify the first
or last columns.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
<!--
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.
-->
Could add one of the new flags to the already existing [Nushell
Fundamentals move
section](https://www.nushell.sh/book/working_with_tables.html#moving-columns).
---------
Signed-off-by: Coca <coca16622@gmail.com>
# Description
This PR fixes#14784.
<img width="384" alt="image"
src="https://github.com/user-attachments/assets/aac063a0-645d-4adb-a399-525bdb004999"
/>
Also fixes the related behavior of lsp:
completion won't work in match/else blocks, because:
1. truncation in completion causes unmatched `{`, thus a parse error.
2. the parse error further leads to a state where the whole block
expression marked as garbage
<img width="453" alt="image"
src="https://github.com/user-attachments/assets/aaf86ccc-646e-4b91-bb27-4b1737100ff2"
/>
Related PR: #14856, @tmillr
I don't have any background knowledge of those `propagate_error`,
@sgvictorino you may want to review this.
# User-Facing Changes
# Tests + Formatting
# After Submitting
<!--
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.
-->
It seems in my PR #14927 I missed a few calls to `IoError::new` that had
`Span::unknown` inside them, which shouldn't be used but rather
`IoError::new_internal`. I replaced these calls.
Thanks to @132ikl to finding out that I forgot some. 😄
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Pretty much none really.
# 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.
-->
<!--
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.
-->
Fixes completion for when the cursor is inside a block:
```nu
foo | each { open -<Tab> }
```
```nu
print (open -<Tab>)
print [5, 'foo', (open -<Tab>)]
```
etc.
Fixes: #11084
Related: #13897 (partially fixes—leading `|` is a different issue)
Related: #14643 (different issue not fixed by this pr)
Related: #14822
## User-Facing Changes
Flag/command completion (internal) inside blocks has been fixed.
## Tests + Formatting
<!--
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
> ```
-->
As far as I can tell there is only 1 test that's failing (locally), but
it has nothing to do with my pr and is failing before my changes are
applied. The test is `completions::variables_completions`. It's because
I'm missing `$nu.user-autoload-dirs`.
`std/core` is always loaded by Nushell during startup, and the
commands in it are always available. As such, it's renamed
`std/prelude`.
`scope modules` and `view files` now show `prelude` in place of
`core`.
# Description
For nu scripts completion with command `use`/`overlay use`/`source-env`,
it now supports `nu --include-path`.
Also fixes some irrelevant clippy complaints.
# User-Facing Changes
# Tests + Formatting
# After Submitting
Bumps [brotli](https://github.com/dropbox/rust-brotli) from 6.0.0 to
7.0.0.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/dropbox/rust-brotli/commits">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>
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
As an avid `cargo doc` enjoyer I realized we had some doc warnings, so I
fixed them.
After this PR `cargo doc --workspace` should stop throwing warnings.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No code 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
> ```
-->
- 🟢 `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.
-->
We could add a `cargo doc` CI pipeline but usually running a full `cargo
doc` takes like forever, so maybe we don't want that.
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
As mentioned in #10698, we have too many `ShellError` variants, with
some even overlapping in meaning. This PR simplifies and improves I/O
error handling by restructuring `ShellError` related to I/O issues.
Previously, `ShellError::IOError` only contained a message string,
making it convenient but overly generic. It was widely used without
providing spans (#4323).
This PR introduces a new `ShellError::Io` variant that consolidates
multiple I/O-related errors (except for `ShellError::NetworkFailure`,
which remains distinct for now). The new `ShellError::Io` variant
replaces the following:
- `FileNotFound`
- `FileNotFoundCustom`
- `IOInterrupted`
- `IOError`
- `IOErrorSpanned`
- `NotADirectory`
- `DirectoryNotFound`
- `MoveNotPossible`
- `CreateNotPossible`
- `ChangeAccessTimeNotPossible`
- `ChangeModifiedTimeNotPossible`
- `RemoveNotPossible`
- `ReadingFile`
## The `IoError`
`IoError` includes the following fields:
1. **`kind`**: Extends `std::io::ErrorKind` to specify the type of I/O
error without needing new `ShellError` variants. This aligns with the
approach used in `std::io::Error`. This adds a second dimension to error
reporting by combining the `kind` field with `ShellError` variants,
making it easier to describe errors in more detail. As proposed by
@kubouch in [#design-discussion on
Discord](https://discord.com/channels/601130461678272522/615329862395101194/1323699197165178930),
this helps reduce the number of `ShellError` variants. In the error
report, the `kind` field is displayed as the "source" of the error,
e.g., "I/O error," followed by the specific kind of I/O error.
2. **`span`**: A non-optional field to encourage providing spans for
better error reporting (#4323).
3. **`path`**: Optional `PathBuf` to give context about the file or
directory involved in the error (#7695). If provided, it’s shown as a
help entry in error reports.
4. **`additional_context`**: Allows adding custom messages when the
span, kind, and path are insufficient. This is rendered in the error
report at the labeled span.
5. **`location`**: Sometimes, I/O errors occur in the engine itself and
are not caused directly by user input. In such cases, if we don’t have a
span and must set it to `Span::unknown()`, we need another way to
reference the error. For this, the `location` field uses the new
`Location` struct, which records the Rust file and line number where the
error occurred. This ensures that we at least know the Rust code
location that failed, helping with debugging. To make this work, a new
`location!` macro was added, which retrieves `file!`, `line!`, and
`column!` values accurately. If `Location::new` is used directly, it
issues a warning to remind developers to use the macro instead, ensuring
consistent and correct usage.
### Constructor Behavior
`IoError` provides five constructor methods:
- `new` and `new_with_additional_context`: Used for errors caused by
user input and require a valid (non-unknown) span to ensure precise
error reporting.
- `new_internal` and `new_internal_with_path`: Used for internal errors
where a span is not available. These methods require additional context
and the `Location` struct to pinpoint the source of the error in the
engine code.
- `factory`: Returns a closure that maps an `std::io::Error` to an
`IoError`. This is useful for handling multiple I/O errors that share
the same span and path, streamlining error handling in such cases.
## New Report Look
This is simulation how the I/O errors look like (the `open crates` is
simulated to show how internal errors are referenced now):
## `Span::test_data()`
To enable better testing, `Span::test_data()` now returns a value
distinct from `Span::unknown()`. Both `Span::test_data()` and
`Span::unknown()` refer to invalid source code, but having a separate
value for test data helps identify issues during testing while keeping
spans unique.
## Cursed Sneaky Error Transfers
I removed the conversions between `std::io::Error` and `ShellError` as
they often removed important information and were used too broadly to
handle I/O errors. This also removed the problematic implementation
found here:
7ea4895513/crates/nu-protocol/src/errors/shell_error.rs (L1534-L1583)
which hid some downcasting from I/O errors and made it hard to trace
where `ShellError` was converted into `std::io::Error`. To address this,
I introduced a new struct called `ShellErrorBridge`, which explicitly
defines this transfer behavior. With `ShellErrorBridge`, we can now
easily grep the codebase to locate and manage such conversions.
## Miscellaneous
- Removed the OS error added in #14640, as it’s no longer needed.
- Improved error messages in `glob_from` (#14679).
- Trying to open a directory with `open` caused a permissions denied
error (it's just what the OS provides). I added a `is_dir` check to
provide a better error in that case.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
- Error outputs now include more detailed information and are formatted
differently, including updated error codes.
- The structure of `ShellError` has changed, requiring plugin authors
and embedders to update their implementations.
# 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
> ```
-->
I updated tests to account for the new I/O error structure and
formatting changes.
# 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.
-->
This PR closes#7695 and closes#14892 and partially addresses #4323 and
#10698.
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
This fixes#14039
<!--
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.
-->
# User-Facing Changes
Pressing `esc` or `q` in expand and try view no longer closes explore.
This is not intentional
<!-- 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 fixes#14816 , so that expression-contains-position check won't
need special treatment for keyword expressions.
e.g.
```nushell
overlay use foo as bar
# |_______ cursor here
if true { } else { }
# |_______ here
```
as mentioned in #14924
# User-Facing Changes
# Tests + Formatting
# After Submitting
# Description
This PR enables basic goto def/hover features on module name in
commands:
1. hide
2. overlay use
3. overlay hide
## Some pending issues
1. Somewhat related to #14816
```nushell
overlay use foo as bar
# |_______ cursor here
```
fails to work, since the position of the cursor is outside of the whole
span of this call expression.
I'll try to fix#14816 later instead of implementing new weird
workarounds.
2. references/renaming however is still buggy on overlays with
`as`/`--prefix` features enabled.
# User-Facing Changes
# Tests + Formatting
3 more tests
# After Submitting
<!--
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 a new command that outputs a NuDataFrame or NuLazyFrame in
its repr format, which can then be ingested in another polars instance.
Advantages of serializing a dataframe in this format are that it can be
viewed as a table, carries type information, and can easily be copied to
the clipboard.
```nushell
# In Nushell
> [[a b]; [2025-01-01 2] [2025-01-02 4]] | polars into-df | polars into-lazy | polars into-repr
shape: (2, 2)
┌─────────────────────┬─────┐
│ a ┆ b │
│ --- ┆ --- │
│ datetime[ns] ┆ i64 │
╞═════════════════════╪═════╡
│ 2025-01-01 00:00:00 ┆ 2 │
│ 2025-01-02 00:00:00 ┆ 4 │
└─────────────────────┴─────┘
```
```python
# In python
>>> import polars as pl
>>> df = pl.from_repr("""
... shape: (2, 2)
... ┌─────────────────────┬─────┐
... │ a ┆ b │
... │ --- ┆ --- │
... │ datetime[ns] ┆ i64 │
... ╞═════════════════════╪═════╡
... │ 2025-01-01 00:00:00 ┆ 2 │
... │ 2025-01-02 00:00:00 ┆ 4 │
... └─────────────────────┴─────┘""")
shape: (2, 2)
┌─────────────────────┬─────┐
│ a ┆ b │
│ --- ┆ --- │
│ datetime[ns] ┆ i64 │
╞═════════════════════╪═════╡
│ 2025-01-01 00:00:00 ┆ 2 │
│ 2025-01-02 00:00:00 ┆ 4 │
└─────────────────────┴─────┘
>>> df.select(pl.col("a").dt.offset_by("12m"))
shape: (2, 1)
┌─────────────────────┐
│ a │
│ --- │
│ datetime[ns] │
╞═════════════════════╡
│ 2025-01-01 00:12:00 │
│ 2025-01-02 00:12:00 │
└─────────────────────┘
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
A new command `polars into-repr` is added. No other commands are
impacted by the changes in this PR.
# 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
> ```
-->
Examples were added in the command definition.
# 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
In a few places, `nu-path` uses `unsafe` to do reference casts. This PR
adds the [`ref-cast`](https://crates.io/crates/ref-cast) crate to do
reference casts in a "safe" manner.
# Description
This PR replaces most of the constants in `ResolvedImportPattern` from
values to VarIds, this has benefits of:
1. less duplicated variables in state
2. precise span of variable, for example when calling `goto def` on a
const imported by the `use` command, this allows it to find the original
definition, instead of where the `use` command is.
Note that the logic is different here for nested submodules, not all
values are flattened and propagated to the outmost record variable, but
I didn't find any differences in real world usage.
I noticed that it was changed from `VarId` to `Value` in #10049.
Maybe @kubouch can find some edge cases where this PR fails to work as
expected.
In my view, the record constants for `ResolvedImportPattern` should even
reduced to single entry, if not able to get rid of.
# User-Facing Changes
# Tests + Formatting
# After Submitting
# Description
Fixes#14909 with the same technique used in #12820 for `stor insert`.
Single quotes (and others) now work properly in strings passed to `stor
update`. Also did some minor refactoring on `stor insert` so it matches
the changes in `stor update`.
# User-Facing Changes
Bug-fix.
# Tests + Formatting
Test added for this scenario.
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
N/A
# Description
Closes#14595. This modifies the behavior of both custom and external
completers so that if the custom/external completer returns an invalid
value, completions are suppressed and an error is logged. However, if
the completer returns `null` (which this PR treats as a special value),
we fall back to file completions.
Previously, custom completers and external completers had different
behavior. Any time an external completer returned an invalid value
(including `null`), we would fall back to file completions. Any time a
custom completer returned an invalid value (including `null`), we would
suppress completions.
I'm not too happy about the implementation, but it's the least intrusive
way I could think of to do it. I added a `fallback` field to
`CustomCompletions` that's checked after calling its `fetch()` method.
If `fallback` is true, then we use file completions afterwards.
An alternative would be to make `CustomCompletions` no longer implement
the `Completer` trait, and instead have its `fetch()` method return an
`Option<Vec<Suggestion>>`. But that resulted in a teeny bit of code
duplication.
# User-Facing Changes
For those using an external completer, if they want to fall back to file
completions on invalid values, their completer will have to explicitly
return `null`. Returning `"foo"` or something will no longer make
Nushell use file completions instead.
For those making custom completers, they now have the option to fall
back to file completions.
# Tests + Formatting
Added some tests and manually tested that if the completer returns an
invalid value or the completer throws an error, that gets logged and
completions are suppressed.
# After Submitting
The documentation for custom completions and external completers will
have to be updated after this.
# Description
With the fragmentation and proliferation of social media platforms,
we're attempting to consolidate our news and official Nushell
communications to:
* The Nushell website, with updates posted on the Blog
* Discord
* GitHub
This PR replaces Twitter with the Nushell Blog in the welcome banner.
The other links were already available.
# User-Facing Changes
Welcome banner
# Tests + Formatting
# After Submitting
<!--
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 seeks to generalize the `seq date` command so that it can
receive any duration as an `--increment`. Whereas the current command
can only output a list of dates spaced at least 1 day apart, the new
command can output a list of datetimes that are spaced apart by any
duration.
For example:
```
> seq date --begin-date 2025-01-01 --end-date 2025-01-02 --increment 6hr --output-format "%Y-%m-%d %H:%M:%S"
╭───┬─────────────────────╮
│ 0 │ 2025-01-01 00:00:00 │
│ 1 │ 2025-01-01 06:00:00 │
│ 2 │ 2025-01-01 12:00:00 │
│ 3 │ 2025-01-01 18:00:00 │
│ 4 │ 2025-01-02 00:00:00 │
╰───┴─────────────────────╯
```
Note that the default behavior remains unchanged:
```
> seq date --begin-date 2025-01-01 --end-date 2025-01-02
╭───┬────────────╮
│ 0 │ 2025-01-01 │
│ 1 │ 2025-01-02 │
╰───┴────────────╯
```
The default output format also remains unchanged:
```
> seq date --begin-date 2025-01-01 --end-date 2025-01-02 --increment 6hr
╭───┬────────────╮
│ 0 │ 2025-01-01 │
│ 1 │ 2025-01-01 │
│ 2 │ 2025-01-01 │
│ 3 │ 2025-01-01 │
│ 4 │ 2025-01-02 │
╰───┴────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
## Breaking Changes
* The `--increment` argument no longer accepts just an integer and
requires a duration
```
# NEW BEHAVIOR
> seq date --begin-date 2025-01-01 --end-date 2025-01-02 --increment 1
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry #13:1:68]
1 │ seq date --begin-date 2025-01-01 --end-date 2025-01-02 --increment 1
· ┬
· ╰── expected duration with valid units
╰────
```
EDIT: Break Change is mitigated. `--increment` accepts either an integer
or duration.
## Bug Fix
* The `--days` argument had an off-by-one error and would print 1 too
many elements in the output. For example,
```
# OLD BEHAVIOR
> seq date -b 2025-01-01 --days 5 --increment 1
╭───┬────────────╮
│ 0 │ 2025-01-01 │
│ 1 │ 2025-01-02 │
│ 2 │ 2025-01-03 │
│ 3 │ 2025-01-04 │
│ 4 │ 2025-01-05 │
│ 5 │ 2025-01-06 │ <-- Extra element
╰───┴────────────╯
# NEW BEHAVIOR
> seq date -b 2025-01-01 --days 5 --increment 1day
╭───┬────────────╮
│ 0 │ 2025-01-01 │
│ 1 │ 2025-01-02 │
│ 2 │ 2025-01-03 │
│ 3 │ 2025-01-04 │
│ 4 │ 2025-01-05 │
╰───┴────────────╯
```
## New Argument
* A `--periods` argument is introduced to indicate the number of output
elements, regardless of the `--increment` value. Importantly, the
`--days` argument is ignored when `--periods` is set.
```
# NEW BEHAVIOR
> seq date -b 2025-01-01 --days 5 --periods 10 --increment 1day
╭───┬────────────╮
│ 0 │ 2025-01-01 │
│ 1 │ 2025-01-02 │
│ 2 │ 2025-01-03 │
│ 3 │ 2025-01-04 │
│ 4 │ 2025-01-05 │
│ 5 │ 2025-01-06 │
│ 6 │ 2025-01-07 │
│ 7 │ 2025-01-08 │
│ 8 │ 2025-01-09 │
│ 9 │ 2025-01-10 │
╰───┴────────────╯
```
Note that the `--days` and `--periods` arguments differ in their
functions. The `--periods` value determines the number of elements in
the output that are always spaced `--increment` apart. The `--days`
value determines the bookends `--begin-date` and `--end-date` when only
one is set, though the number of elements may differ based on the
`--increment` value.
```
# NEW BEHAVIOR
> seq date -e 2025-01-01 --days 2 --increment 5hr --output-format "%Y-%m-%d %H:%M:%S"
╭───┬─────────────────────╮
│ 0 │ 2025-01-23 22:25:05 │
│ 1 │ 2025-01-24 03:25:05 │
│ 2 │ 2025-01-24 08:25:05 │
│ 3 │ 2025-01-24 13:25:05 │
│ 4 │ 2025-01-24 18:25:05 │
╰───┴─────────────────────╯
```
# 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
> ```
-->
I added several examples for each user-facing change in
`generators/seq_date.rs` and some tests in `tests/commands/seq_date.rs`.
# 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
Closes#14904. The bug there was introduced by #14846, which replaced
skim with Nucleo. It turns out that Nucleo's `Pattern::new` function
doesn't treat the needle as a single atom - it splits on spaces and
makes each word its own atom. This PR fixes the problem by creating a
single `Atom` for the whole needle rather than creating a `Pattern`.
Because of the bug, when you typed `lines <TAB>` (with a space at the
end), the suggestion `lines` was also matched. This suggestion was
shorter than the original typed needle, which would cause an
out-of-bounds error.
This also meant that if you typed `foo bar<TAB>`, `foo aaaaa bar` would
be shown before `foo bar aaa`. At the time, I didn't realize that it was
more intuitive to have `foo bar aaa` be put first.
# User-Facing Changes
Typing something like `lines <TAB>` should no longer cause a panic.
# Tests + Formatting
- Added a test to ensure spaces are respected when fuzzy matching
- Updated a test with the changed sort order for subcommand suggestions
# After Submitting
No need to update docs.
# Description
This PR adds those markdown doc strings (previously only available via
hover) to completion items:
<img width="676" alt="image"
src="https://github.com/user-attachments/assets/58c44d7d-4b49-4955-b3f0-fa7a727a8bc0"
/>
It also refactors a bit, primarily to prevent namespace pollution.
# User-Facing Changes
# Tests + Formatting
# After Submitting
# Description
this PR should close#14315
This PR enhances the start command in Nushell to handle both files and
URLs more effectively, including support for custom URL schemes.
Previously, the start command only reliably opened HTTP and HTTPS URLs,
and custom schemes like Spotify and Obsidian which were not handled
earlier.
1. **Custom URL Schemes Support:**
- Added support for opening custom URL schemes
2. **Detailed Error Messages:**
- Improved error reporting for failed external commands.
- Captures and displays error output from the system to aid in
debugging.
**Example**
**Opening a custom URL scheme (e.g., Spotify):**
```bash
start spotify:track:4PTG3Z6ehGkBFwjybzWkR8?si=f9b4cdfc1aa14831
```
Opens the specified track in the Spotify application.
**User-Facing Changes**
- **New Feature:** The start command now supports opening URLs with
custom schemes
# Description
This PR supersedes https://github.com/nushell/nushell/pull/14813 by
making it a built-in command instead of checking for the latest version
at some interval when nushell starts.
This is what it looks like.
This example shows the output when the running version was
0.101.1-nightly.10
Description from old PR.
One key functionality that I thought was interesting with this and that
I worked with @hustcer on was to try and make sure it works with
nightlies. So, it should tell you when there's a new nightly version
that is available to download. This way, you can know about it without
checking.
What's key from a nightly perspective is (1) the tags are now semver
compliant and (2) hustcer now updates the Cargo.toml package.version
version number prior to compilation so you can know you're running a
nightly version, and this PR uses that information to know whether to
check the nightly repo or the nushell repo for updates.
This uses the
[update-informer](https://docs.rs/update-informer/latest/update_informer/)
crate. NOTE that this _informs_ you of updates but does not
automatically update. I kind of see this as the first step to eventually
having an auto updater.
There was caching of the version in the old PR since it ran on every
nushell startup. Since this PR makes it a command and therefore always
runs on-demand, I've removed the caching so that it always checks when
you run it.
# 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.
-->
This is a minor feature that highlights all occurrences of current
variable/command in current file:
<img width="346" alt="image"
src="https://github.com/user-attachments/assets/f1078e79-d02e-480e-b84a-84efb222c9a4"
/>
Since this kind of request happens a lot with fixed document content, to
avoid unnecessary parsing, this PR caches the `StateDelta` to the
server.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Can be disabled on the client side.
# 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
> ```
-->
Implementation is directly borrowed from `references`, only one simple
test case added.
# 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 cleans up the code surrounding formatting and displaying file
sizes.
- The `byte_unit` crate we use for file size units displays kilobytes as
`KB`, which is not the SI or ISO/IEC standard. Rather it should be `kB`,
so this fixes#8872. On some systems, `KB` actually means `KiB`, so this
avoids any potential confusion.
- The `byte_unit` crate, when displaying file sizes, casts integers to
floats which will lose precision for large file sizes. This PR adds a
custom `Display` implementation for `Filesize` that can give an exact
string representation of a `Filesize` for metric/SI units.
- This PR also removes the dependency on the `byte_unit` crate which
brought in several other dependencies.
Additionally, this PR makes some changes to the config for filesize
formatting (`$env.config.filesize`).
- The previous filesize config had the `metric` and `format` options. If
a metric (SI) unit was set in `format`, but `metric` was set to false,
then the `metric` option would take precedence and convert `format` to
the corresponding binary unit (or vice versa). E.g., `{ format: kB,
metric: false }` => `KiB`. Instead, this PR adds the `unit` option to
replace the `format` and `metric` options. `unit` can be set to a fixed
file size unit like `kB` or `KiB`, or it can be set to one of the
special options: `binary` or `metric`. These options tells nushell to
format file sizes using an appropriately scaled metric or binary unit
(examples below).
```nushell
# precision = null
# unit = kB
1kB # 1 kB
1KiB # 1.024 kB
# unit = KiB
1kB # 0.9765625 KiB
1KiB # 1 KiB
# unit = metric
1000B # 1 kB
1024B # 1.024 kB
10_000MB # 10 GB
10_240MiB # 10.73741824 GB
# unit = binary
1000B # 1000 B
1024B # 1 KiB
10_000MB # 9.313225746154785 GiB
10_240MiB # 10 GiB
```
- In addition, this PR also adds the `precision` option to the filesize
config. It determines how many digits to show after the decimal point.
If set to null, then everything after the decimal point is shown.
- The default filesize config is `{ unit: metric, precision: 1 }`.
# User-Facing Changes
- Commands that use the config to format file sizes will follow the
changes described above (e.g., `table`, `into string`, `to text`, etc.).
- The file size unit/format passed to `format filesize` is now case
sensitive. An error with the valid units is shown if the case does not
match.
- `$env.config.filesize.format` and `$env.config.filesize.metric` are
deprecated and replaced by `$env.config.filesize.unit`.
- A new `$env.config.filesize.precision` option was added.
# Tests + Formatting
Mostly updated test expected outputs.
# After Submitting
This PR does not change the way NUON serializes file sizes, because that
would require changing the nu parser to be able to losslessly decode the
new, exact string representation introduced in this PR.
Similarly, this PR also does not change the file size parsing in any
way. Although the file size units provided to `format filesize` or the
filesize config are now case-sensitive, the same is not yet true for
file size literals in nushell code.
<!--
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.
-->
A simple method found by @tmillr to solve [this
issue](https://github.com/nushell/nushell/discussions/14854)
# 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
> ```
-->
I didn't find a suitable place in `nu-parser` to add the test case,
placed in `nu-lsp` instead.
# 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.
-->
Sorry was a little bit busy
close#14842
I've added a test but I'd check if it solved it.
cc: @fdncred
__________________________
**Unrelated**
Recently got a pretty good format idea
(https://github.com/zhiburt/tabled/issues/472)
Just wanna highlight that we could probably experiment with it, if it
being a bit elaborated.
It's sort of KV table which nushell already has,
But it's more for a default table where each row/record being rendered
as a KV table.
It's not something super nice I guess but maybe it could get some
appliance.
So yes pointing it out just in case.
Like these.
```
┌──────────────┬───────────────────────────────────────────────┐
│ Field │ Value │
├──────────────┼───────────────────────────────────────────────┤
│ Company │ INTEL CORP │
├──────────────┼───────────────────────────────────────────────┤
│ Street │ 2200 MISSION COLLEGE BLVD, RNB-4-151 │
├──────────────┼───────────────────────────────────────────────┤
│ City │ SANTA CLARA │
├──────────────┼───────────────────────────────────────────────┤
│ ZIP code │ 95054 │
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
│ Company │ Apple Inc. │
├──────────────┼───────────────────────────────────────────────┤
│ Street │ ONE APPLE PARK WAY │
├──────────────┼───────────────────────────────────────────────┤
│ City │ CUPERTINO │
├──────────────┼───────────────────────────────────────────────┤
│ ZIP code │ 95014 │
└──────────────┴───────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ INTEL CORP │
├──────────────┬───────────────────────────────────────────────┤
│ Street │ 2200 MISSION COLLEGE BLVD, RNB-4-151 │
├──────────────┼───────────────────────────────────────────────┤
│ City │ SANTA CLARA │
├──────────────┼───────────────────────────────────────────────┤
│ ZIP code │ 95054 │
├──────────────┴───────────────────────────────────────────────┤
│ Apple Inc. │
├──────────────┬───────────────────────────────────────────────┤
│ Street │ ONE APPLE PARK WAY │
├──────────────┼───────────────────────────────────────────────┤
│ City │ CUPERTINO │
├──────────────┼───────────────────────────────────────────────┤
│ ZIP code │ 95014 │
└──────────────┴───────────────────────────────────────────────┘
```
PS: Now thinking about it,
it's sort of like doing a iteration over rows and building a current KV
table,
Which is interesting cause we could do it row by row, in which case
doing CTRLC would not ruin build but got some data rendered.
All though it's a different kind of approach. Just saying.
Bumps [similar](https://github.com/mitsuhiko/similar) from 2.6.0 to
2.7.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/mitsuhiko/similar/blob/main/CHANGELOG.md">similar's
changelog</a>.</em></p>
<blockquote>
<h2>2.7.0</h2>
<ul>
<li>Add optional support for <code>web-time</code> to support web WASM
targets. <a
href="https://redirect.github.com/mitsuhiko/similar/issues/73">#73</a></li>
<li>Crate will no longer panic wheh deadlines are used in WASM. At worst
deadlines are silently ignored. To enforce deadlines enable the
<code>wasm32_web_time</code> feature. <a
href="https://redirect.github.com/mitsuhiko/similar/issues/74">#74</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="28c146b628"><code>28c146b</code></a>
2.7.0</li>
<li><a
href="3ec4464a26"><code>3ec4464</code></a>
Added another changelog entry</li>
<li><a
href="5077768172"><code>5077768</code></a>
Add wasm tests (<a
href="https://redirect.github.com/mitsuhiko/similar/issues/74">#74</a>)</li>
<li><a
href="2b2881a375"><code>2b2881a</code></a>
Added web-time changelog entry</li>
<li><a
href="177ce9e700"><code>177ce9e</code></a>
Add wasm32_web_time feature (<a
href="https://redirect.github.com/mitsuhiko/similar/issues/73">#73</a>)</li>
<li><a
href="717757e156"><code>717757e</code></a>
Another clippy fix</li>
<li><a
href="157f01564d"><code>157f015</code></a>
Make clippy happier (<a
href="https://redirect.github.com/mitsuhiko/similar/issues/72">#72</a>)</li>
<li>See full diff in <a
href="https://github.com/mitsuhiko/similar/compare/2.6.0...2.7.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>
<!--
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 fixes a bug: renaming on a flag variable removes the leading
`--` in the signature.
<img width="257" alt="image"
src="https://github.com/user-attachments/assets/767c62de-f3a0-4a07-9786-61b21e8cfcb6"
/>
Gets the following before this PR:
```nushell
export def foooo [
p: int
] {
$p
}
```
# 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
Should fix#14872.
## Before
The vendor autoload code in #13382 used `dirs::data_dir()`
(from the `dirs` crate), leading to a different behavior when
`XDG_DATA_HOME` is set on each platform.
* On Linux, the `dirs` crate automatically uses `XDG_DATA_HOME` for
`dirs::data_dir()`, so everything worked as expected.
* On macOS, `dirs` doesn't use the XDG spec, but the vendor autoload
code from #13382 specifically added `XDG_DATA_HOME`. However, even if
`XDG_DATA_HOME` was set, vendor autoloads would still use the `dirs`
version *as well*.
* On Windows, `XDG_DATA_HOME` was ignored completely by vendor
autoloads, even though `$nu.data-dirs` was respecting it.
## After
This PR uses `nu::data_dirs()` on all platforms. `nu::data_dirs()`
respects `XDG_DATA_HOME` (if set) on all platforms.
# User-Facing Changes
Might be a breaking change if someone was depending on the old behavior,
but the doc already specified the behavior in this PR.
<!--
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.
-->
https://github.com/nushell/nushell/pull/14845#issuecomment-2596371878
When the input to `into cell-path` is a cell-path, it will return it
like other into commands.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Before, using `into cell-path` with a cell-path as input would return an
error, now it will return the input.
<!--
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
> ```
-->
<!-- 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.
-->
https://github.com/nushell/nushell/pull/14845#issuecomment-2596371878
When the input to `into glob` is a glob, it will return it like other
into commands.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Before, using `into glob` with a glob as input would return an error,
now it will return the input.
<!--
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
> ```
-->
<!-- 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 renames `fmt` to `format number`, to bring it in line with
similar value formatting commands and make it more discoverable.
# User-Facing Changes
* The `fmt` command is now `format number`. A deprecation warning will
be thrown if you use `fmt`.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
N/A
# Description
Fixes an issue with #14669 - I mistakenly used `dirs::config_dir()` when
it should be `nu_path::config_dir()`. This allows `XDG_CONFIG_DIR` to
specify the location properly.
# User-Facing Changes
Fix: If `XDG_CONFIG_DIR` is set, it will be used for the `autoload`
location.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# 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 fixes the issue of the missing references in `use` command
<img width="832" alt="image"
src="https://github.com/user-attachments/assets/f67cd4b3-2e50-4dda-b2ed-c41aee86d3e9"
/>
However, as described in [this
discussion](https://github.com/nushell/nushell/discussions/14854), the
returned reference list is still not complete due to the inconsistent
IDs.
As a side effect, `hover/goto def` now also works on the `use` command
arguments
<img width="752" alt="image"
src="https://github.com/user-attachments/assets/e0abdc9e-097a-44c2-9084-8d7905ae1d5e"
/>
Actions including `goto def/hover/references/rename` now work with
module (maybe some edge cases of `overlay` are not covered)
<img width="571" alt="image"
src="https://github.com/user-attachments/assets/b4edb9b7-1540-4c52-bf8b-145bc6a1ad4a"
/>
# 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
> ```
-->
Added
1. the test for heavy requests cancellation.
2. expected Edit for the missing ref of `use` to the existing rename
test.
3. `goto/hover` on module name
# 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.
-->
`tower-lsp` seems not well-maintained, I ended up with a dedicated
thread for heavy computing and message passing to cancel it on any new
request.
During the progress, interrupting with edits or new requests.
<img width="522" alt="image"
src="https://github.com/user-attachments/assets/b263d73d-8ea3-4b26-a7b7-e0b30462d1af"
/>
Goto references are still blocking, with a hard timeout of 5 seconds.
Only locations found within the time limit are returned. Technically,
reference requests allow for responses with partial results, which means
instant responsiveness. However, the `lsp_types` crate hasn’t enabled
this. I believe I can still enable it with some JSON manipulation, but
I’ll leave it for future work.
# 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
> ```
-->
Need some clever way to test the cancellation, no test cases added yet.
# 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 replaces `SkimMatcherV2` from the
[fuzzy-matcher](https://docs.rs/fuzzy-matcher/latest/fuzzy_matcher/)
crate with the
[nucleo-matcher](https://docs.rs/nucleo-matcher/latest/nucleo_matcher/)
crate for doing fuzzy matching. This touches both our completion code in
`nu-cli` and symbol filtering in `nu-lsp`.
Nucleo should give us better performance than Skim. In the event that we
decide to use the Nucleo frontend ([crate
docs](https://docs.rs/nucleo/latest/nucleo/)) too, it also works on
Windows, unlike [Skim](https://github.com/skim-rs/skim), which appears
to only support Linux and MacOS.
Unfortunately, we still have an indirect dependency on `fuzzy-matcher`,
because the [`dialoguer`](https://github.com/console-rs/dialoguer) crate
uses it.
# User-Facing Changes
No breaking changes. Suggestions will be sorted differently, because
Nucleo uses a different algorithm from Skim for matching/scoring.
Hopefully, the new sorting will generally make more sense.
# Tests + Formatting
In `nu-cli`, modified an existing test, but didn't test performance. I
haven't tested `nu-lsp` manually, but existing tests pass.
I did manually do `ls /nix/store/<TAB>`, `ls /nix/store/d<TAB>`, etc.,
but didn't notice Nucleo being faster (my `/nix/store` folder has 34136
items at the time of writing).
# Description
Fixes: #14844
The issue occurs when nushell is parsing a value with
`SyntaxShape::Any`, it checks `Duration` and `Filesize` first, then
`Range`. Nushell raises errors too early while parsing
`Duration/Filesize`.
This pr changes the order of parsing to fix the issue.
# User-Facing Changes
The following code should be able to run after this pr
```nushell
let runs = 10;
1..$runs
```
# Tests + Formatting
Added 2 tests, one for filesize, one for duration.
# After Submitting
NaN
# Description
As the `range` command has an ambiguous name (does it construct a range
type?, does it iterate a range like `seq`) replace it with a more
descriptive verb of what it does: `slice`
Closes#14130
# User-Facing Changes
`range` is now deprecated and replaced in whole by `slice` with the same
behavior.
`range` will be removed in `0.103.0`
# Tests + Formatting
Tests have been updated to use `slice`
# After submitting
- [ ] prepare PR for `nu_scripts` (several usages of `range` to be
fixed)
- [ ] update documentation usages of `range` after release
# Description
This PR add 2 new operators, `has` and `not-has`. They are basically
`in` and `not-in` with the order of operands swapped.
Motivation for this was the awkward way of searching for rows that
contain an item using `where`
```nushell
[[name, children]; [foo, [a, b, c]], [bar [d, e, f]]]
| where ("e" in $it.children)
```
vs
```nushell
[[name, children]; [foo, [a, b, c]], [bar [d, e, f]]]
| where children has "e"
```
# User-Facing Changes
Added `has` and `not-has` operators, mirroring `in` and `not-in`.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
# Description
- Closes#14839
When the input to `into datetime` is a datetime, it will return it like
other `into` commands.
# User-Facing Changes
Before, using `into datetime` with a datetime as input would return an
error, now it will return the input.
# Tests + Formatting
Added test `takes_datetime`.
# After Submitting
Doc file is automatically generated.
- fixes#14801
# Description
- Fixed the issue
- Added some comments mirroring the ones used in `export-env` handling
in `use`
- Added two tests to prevent regressions
# User-Facing Changes
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
# 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.
-->
<!--
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!
-->
goto reference:
<img width="885" alt="image"
src="https://github.com/user-attachments/assets/6f85cd10-0c2d-46b2-b99e-47a9bbf90822"
/>
rename:
<img width="483" alt="image"
src="https://github.com/user-attachments/assets/828e7586-c2b7-414d-9085-5188b10f5f5f"
/>
Caveats:
1. Module reference/rename is not supported yet
2. names in `use` command should also be renamed, which is not handled
now
3. workspace wide actions can be time-consuming, as it requires parsing
of all `**/*.nu` files in the workspace (if its text contains the name).
Added a progress bar for such requests.
4. In case these requests are triggered accidentally in a root folder
with a large depth, I hard-coded the max depth to search to 5 right now.
# 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
> ```
-->
Limited test 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.
-->
This simply replaces uses of the deprecated function `current_dir_str`
with `EngineState::cwd_as_string` in `run_shell_integration_*`
functions. The main difference being that the latter does not
canonicalize paths.
Fixes#14619
Bumps [data-encoding](https://github.com/ia0/data-encoding) from 2.6.0
to 2.7.0.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/ia0/data-encoding/commits">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 replaces the home-grown icons in the `grid` command with the
`devicons` crate.
### 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.
-->
- closes#8523
# Description
This PR adds pipeline input support to `generate`.
- Without input, `generate` keeps its current behavior.
- With input, each invocation of the closure is provided an item from
the input stream as pipeline input (`$in`). If/when the input stream
runs out, `generate` also stops.
Before this PR, there is no filter command that is both stateful _and_
streaming.
This PR also refactors `std/iter scan` to use `generate`, making it
streaming and more performant over larger inputs.
# User-Facing Changes
- `generate` now supports pipeline input, passing each element to the
closure as `$in` until it runs out
- `std/iter scan` is now streaming
# Tests + Formatting
Added tests to validate the new feature.
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
# Description
This pr is going to add a new command named `help pipe-and-redirect`.
So user can detect such feature easier.
# User-Facing Changes
Here is the output of this command:
```
╭───┬────────┬──────────────────────────────────────┬──────────────────────────────────────────────────────────────┬─────────────────────╮
│ # │ symbol │ name │ description │ example │
├───┼────────┼──────────────────────────────────────┼──────────────────────────────────────────────────────────────┼─────────────────────┤
│ 0 │ | │ pipe │ pipeline stdout of a command to another command │ ^cmd1 | ^cmd2 │
│ 1 │ e>| │ stderr pipe │ pipeline stderr of a command to another command │ ^cmd1 e>| ^cmd2 │
│ 2 │ o+e>| │ stdout and stderr pipe │ pipeline stdout and stderr of a command to another command │ ^cmd1 o+e>| ^cmd2 │
│ 3 │ o> │ redirection │ redirect stdout of a command, overwriting a file │ ^cmd1 o> file.txt │
│ 4 │ e> │ stderr redirection │ redirect stderr of a command, overwriting a file │ ^cmd1 e> file.txt │
│ 5 │ o+e> │ stdout and stderr redirection │ redirect stdout and stderr of a command, overwriting a file │ ^cmd1 o+e> file.txt │
│ 6 │ o>> │ redirection append │ redirect stdout of a command, appending to a file │ ^cmd1 o> file.txt │
│ 7 │ e>> │ stderr redirection append │ redirect stderr of a command, appending to a file │ ^cmd1 e> file.txt │
│ 8 │ o+e>> │ stdout and stderr redirection append │ redirect stdout and stderr of a command, appending to a file │ ^cmd1 o+e> file.txt │
│ 9 │ o>| │ │ Unsupported, it's the same to `|`, use it instead │ │
├───┼────────┼──────────────────────────────────────┼──────────────────────────────────────────────────────────────┼─────────────────────┤
│ # │ symbol │ name │ description │ example │
╰───┴────────┴──────────────────────────────────────┴──────────────────────────────────────────────────────────────┴─────────────────────╯
```
# Tests + Formatting
# After Submitting
Should update more examples in [nushell
doc](https://www.nushell.sh/lang-guide/chapters/pipelines.html) to fill
more examples
<!--
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.
-->
Follow-up PR of #14789
The span of `$it/$in` is set to a 0-width one with start/end pointing to
the start of its scope, mainly for error messages positioning.
# 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 is a follow on to https://github.com/nushell/nushell/pull/14423
and finishes removing the `terminal_size` crate in favor of
`crossterm`'s `size()`.
# 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.
-->
This PR fixes a corner case of goto definition in lsp server.
```nushell
let foo = 1
match $foo {
_ if $foo == 1 => 1
# |_______________ goto definition does not work here
_ => 2
}
```
Since `match_pattern.guard` is not handled in this function (which could
be another issue).
23dc1b600a/crates/nu-parser/src/flatten.rs (L604-L658)
In this PR, however, finding leaf expression at the cursor is done with
the new AST traversing helper functions.
Theoretically, this is faster as the flattening and filtering are
combined in a single scan; the difference could be negligible though.
# 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
> ```
-->
3 new test cases added, will add more if new issues found.
# 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.
-->
This is a complementary PR of #14802
<img width="418" alt="image"
src="https://github.com/user-attachments/assets/ddf945e4-7ef0-4c73-a9fd-e68591efce03"
/>
# 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
> ```
-->
new relative test 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.
-->
# Description
This PR should address #13530 by explicitly handling ByteStreams.
The issue can be replicated easily on linux by running:
```nushell
open /dev/urandom | into binary | bytes at ..10
```
Would leave the output hanging and with no way to cancel it, this was
likely because it was trying to collect the input stream and would not
complete.
I have also put in an error to say that using negative offsets for a
bytestream without a length cannot be used.
```nushell
~/git/nushell> open /dev/urandom | into binary | bytes at (-1)..
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #3:1:35]
1 │ open /dev/urandom | into binary | bytes at (-1)..
· ────┬─── ───┬──
· │ ╰── encountered here
· ╰── Negative range values cannot be used with streams that don't specify a length
╰────
```
# User-Facing Changes
No operation changes, only the warning you get back for negative offsets
# Tests + Formatting
Ran `toolkit check pr ` with no errors or warnings
Manual testing of the example commands above
---------
Co-authored-by: Ian Manske <ian.manske@pm.me>
Co-authored-by: Simon Curtis <simon.curtis@candc-uk.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 PR fixes an issue introduced by #14770 , as shown in
https://github.com/nushell/nushell/pull/14802#issuecomment-2585270161
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
The PR follows our standard of bumping the rust compiler when a new one
is released.
/cc @ayax79 @sholderbach
# 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.
-->
This PR adds inlay hints of variable types and parameter names to
lsp-server
<img width="547" alt="image"
src="https://github.com/user-attachments/assets/07a0dd84-5ecc-47df-a8a7-732631715662"
/>
Some design choices I made:
* for composite types like `record<foo: <record ...>>`, only a short
name displayed. Full signature already available through `hover`
* only parameter names of user defined commands are returned, feels too
much distraction if enabled for all builtins
* some information are lost in flattened expressions, so I implemented
my AST traversing functions, which may seem unnecessary, but I can't
find alternatives from the existing code.
* another minor change: added a line separator to current hover markdown
message.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Users who think this feature annoying now have to manually turn it off
(or config the lsp client capabilities).
# 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.
-->
Don't trigger release for nightly tags, more context could be found
here: https://github.com/nushell/nightly/issues/35
<!--
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 addresses the issue of inconsistent spans of special variables
of `$in/$in`, as discussed in
https://github.com/nushell/nushell/pull/14770#discussion_r1908729364.
Instead of making the `declaration_span` to be Option, which will cause
too many changes that we may want to avoid, this PR set the spans to be
`unknown`.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No
# 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.
-->
This PR removes the `std::io::stdout().is_terminal()` check in `table`
again. To ensure that in the future this doesn't happen again, I added a
comment and a test.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Resets the behavior of `table` to #14647 again, after #14415 included it
again.
# 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 new test to check for these color outputs.
- 🟢 `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.
-->
<!--
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.
-->
Today i saw in the general discord channel someone ask what is the
nushell equivalent of `whereis` or `get-command`. I wanted to tell the
user to use our great search via F1 but then I realized that typing in
`whereis` or `get-command` wouldn't really find you something. So I
added these two search terms.
# 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
> ```
-->
I don't think that really needs testing here :D
# 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
Fixes multiple issues related to `ENV_CONVERSION` and
path-conversion-to-list.
* #14681 removed some calls to `convert_env_values()`, but we found that
this caused `nu -n` to no longer convert the path properly.
* `ENV_CONVERSIONS` have apparently never preserved case, meaning a
conversion with a key of `foo` would not update `$env.FOO` but rather
create a new environment variable with a different case.
* There was a partial code-path that attempted to solve this for `PATH`,
but it only worked for `PATH` and `Path`.
* `convert_env_values()`, which handled `ENV_CONVERSIONS` was called in
multiple places in the startup depending on flags.
This PR:
* Refactors the startup to handle the conversion in `main()` rather than
in each potential startup path
* Updates `get_env_var_insensitive()` functions added in #14390 to
return the name of the environment variable with its original case. This
allows code that updates environment variables to preserve the case.
* Makes use of the updated function in `ENV_CONVERSIONS` to preserve the
case of any updated environment variables. The `ENV_CONVERSION` key
itself is still case **insensitive**.
* Makes use of the updated function to preserve the case of the `PATH`
environment variable (normally handled separately, regardless of whether
or not there was an `ENV_CONVERSION` for it).
## Before
`env_convert_values` was run:
* Before the user `env.nu` ran, which included `nu -c <commandstring>`
and `nu <script.nu>`
* Before the REPL loaded, which included `nu -n`
## After
`env_convert_values` always runs once in `main()` before any config file
is processed or the REPL is started
# User-Facing Changes
Bug fixes
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
Added additional tests to prevent future regression.
# After Submitting
There is additional cleanup that should probably be done in
`convert_env_values()`. This function previously handled
`ENV_CONVERSIONS`, but there is no longer any need for this since
`convert_env_vars()` runs whenever `$env.ENV_CONVERSIONS` changes now.
This means that the only relevant task in the old `convert_env_values()`
is to convert the `PATH` to a list, and ensure that it is a list of
strings. It's still calling the `from_string` conversion on every
variable (just once) even though there are no `ENV_CONVERSIONS` at this
point.
Leaving that to another PR though, while we get the core issue fixed
with this one.
<!--
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 a flag to `debug profile` to output the duration field as
Value::Duration. Without the flag, the behavior is same as before: a
column named `duration_ms` which is `Value::Float`. With the flag, there
is instead a column named just `duration` which is `Value::Duration`.
Additionally, this PR changes the time tracking to use nanoseconds
instead of float seconds, so it can be output as either milliseconds or
`Duration` (which uses nanoseconds internally). I don't think overflow
is a concern here, because the maximum amount of time a `Duration` can
store is over 292 years, and if a Nushell instruction takes longer than
that to run then I think we might have bigger issues.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Adds a flag `--duration-values` to `debug profile` which the
`duration_ms` field in `debug profile` to a `duration` field which uses
proper `duration` values.
# 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.
-->
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 adds symbols related features to lsp
<img width="940" alt="image"
src="https://github.com/user-attachments/assets/aeaed338-133c-430a-b966-58a9bc445211"
/>
Notice that symbols of type variable may got filtered by client side
plugins
<img width="906" alt="image"
src="https://github.com/user-attachments/assets/e031b3dc-443a-486f-8a35-4415c07196d0"
/>
# 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.
-->
Bumps [tempfile](https://github.com/Stebalien/tempfile) from 3.14.0 to
3.15.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/Stebalien/tempfile/blob/master/CHANGELOG.md">tempfile's
changelog</a>.</em></p>
<blockquote>
<h2>3.15.0</h2>
<p>Re-seed the per-thread RNG from system randomness when we repeatedly
fail to create temporary files (<a
href="https://redirect.github.com/Stebalien/tempfile/issues/314">#314</a>).
This resolves a potential DoS vector (<a
href="https://redirect.github.com/Stebalien/tempfile/issues/178">#178</a>)
while avoiding <code>getrandom</code> in the common case where it's
necessary. The feature is optional but enabled by default via the
<code>getrandom</code> feature.</p>
<p>For libc-free builds, you'll either need to disable this feature or
opt-in to a different <a
href="https://github.com/rust-random/getrandom?tab=readme-ov-file#opt-in-backends"><code>getrandom</code>
backend</a>.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="e7a40e3731"><code>e7a40e3</code></a>
Release v3.15.0</li>
<li><a
href="ea45f476d7"><code>ea45f47</code></a>
feat: re-seed from system randomness on collision (<a
href="https://redirect.github.com/Stebalien/tempfile/issues/314">#314</a>)</li>
<li><a
href="16209da6e6"><code>16209da</code></a>
Fix link to ticket in changelog (<a
href="https://redirect.github.com/Stebalien/tempfile/issues/310">#310</a>)</li>
<li><a
href="ae22b273a1"><code>ae22b27</code></a>
docs: add owasp link on insecure temporary files (<a
href="https://redirect.github.com/Stebalien/tempfile/issues/309">#309</a>)</li>
<li>See full diff in <a
href="https://github.com/Stebalien/tempfile/compare/v3.14.0...v3.15.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>
Related:
- #14329
- #13872
- #8214
# Description & User-Facing Changes
This PR allows enables the following uses, which are all no-op.
```nushell
source null
source-env null
use null
overlay use null
```
The motivation for this change is conditional sourcing of files. For
example, with this change `login.nu` may be deprecated and replaced with
the following code in `config.nu`
```nushell
const login_module = if $nu.is-login { "login.nu" } else { null }
source $login_module
```
# Tests + Formatting
I'm hoping for CI to pass 😄
# After Submitting
Add a part about the conditional sourcing pattern to the website.
<!--
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.
-->
Re-removes the tests for `split_by`, which was removed in #14726 and
accidentally re-introduced by #14741
cc @fdncred
# 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
> ```
-->
N/A
# 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
<!--
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 type checking of all command input types at run-time.
Generally, these errors should be caught by the parser, but sometimes we
can't know the type of a value at parse-time. The simplest example is
using the `echo` command, which has an output type of `any`, so
prefixing a literal with `echo` will bypass parse-time type checking.
Before this PR, each command has to individually check its input types.
This can result in scenarios where the input/output types don't match
the actual command behavior. This can cause valid usage with an
non-`any` type to become a parse-time error if a command is missing that
type in its pipeline input/output (`drop nth` and `history import` do
this before this PR). Alternatively, a command may not list a type in
its input/output types, but doesn't actually reject that type in its
code, which can have unintended side effects (`get` does this on an
empty pipeline input, and `sort` used to before #13154).
After this PR, the type of the pipeline input is checked to ensure it
matches one of the input types listed in the proceeding command's
input/output types. While each of the issues in the "before this PR"
section could be addressed with each command individually, this PR
solves this issue for _all_ commands.
**This will likely cause some breakage**, as some commands have
incorrect input/output types, and should be adjusted. Also, some scripts
may have erroneous usage of commands. In writing this PR, I discovered
that `toolkit.nu` was passing `null` values to `str join`, which doesn't
accept nothing types (if folks think it should, we can adjust it in this
PR or in a different PR). I found some issues in the standard library
and its tests. I also found that carapace's vendor script had an
incorrect chaining of `get -i`:
```nushell
let expanded_alias = (scope aliases | where name == $spans.0 | get -i 0 | get -i expansion)
```
Before this PR, if the `get -i 0` ever actually did evaluate to `null`,
the second `get` invocation would error since `get` doesn't operate on
`null` values. After this PR, this is immediately a run-time error,
alerting the user to the problematic code. As a side note, we'll need to
PR this fix (`get -i 0 | get -i expansion` -> `get -i 0.expansion`) to
carapace.
A notable exception to the type checking is commands with input type of
`nothing -> <type>`. In this case, any input type is allowed. This
allows piping values into the command without an error being thrown. For
example, `123 | echo $in` would be an error without this exception.
Additionally, custom types bypass type checking (I believe this also
happens during parsing, but not certain)
I added a `is_subtype` method to `Value` and `PipelineData`. It
functions slightly differently than `get_type().is_subtype()`, as noted
in the doccomments. Notably, it respects structural typing of lists and
tables. For example, the type of a value `[{a: 123} {a: 456, b: 789}]`
is a subtype of `table<a: int>`, whereas the type returned by
`Value::get_type` is a `list<any>`. Similarly, `PipelineData` has some
special handling for `ListStream`s and `ByteStream`s. The latter was
needed for this PR to work properly with external commands.
Here's some examples.
Before:
```nu
1..2 | drop nth 1
Error: nu::parser::input_type_mismatch
× Command does not support range input.
╭─[entry #9:1:8]
1 │ 1..2 | drop nth 1
· ────┬───
· ╰── command doesn't support range input
╰────
echo 1..2 | drop nth 1
# => ╭───┬───╮
# => │ 0 │ 1 │
# => ╰───┴───╯
```
After this PR, I've adjusted `drop nth`'s input/output types to accept
range input.
Before this PR, zip accepted any value despite not being listed in its
input/output types. This caused different behavior depending on if you
triggered a parse error or not:
```nushell
1 | zip [2]
# => Error: nu::parser::input_type_mismatch
# =>
# => × Command does not support int input.
# => ╭─[entry #3:1:5]
# => 1 │ 1 | zip [2]
# => · ─┬─
# => · ╰── command doesn't support int input
# => ╰────
echo 1 | zip [2]
# => ╭───┬───────────╮
# => │ 0 │ ╭───┬───╮ │
# => │ │ │ 0 │ 1 │ │
# => │ │ │ 1 │ 2 │ │
# => │ │ ╰───┴───╯ │
# => ╰───┴───────────╯
```
After this PR, it works the same in both cases. For cases like this, if
we do decide we want `zip` or other commands to accept any input value,
then we should explicitly add that to the input types.
```nushell
1 | zip [2]
# => Error: nu::parser::input_type_mismatch
# =>
# => × Command does not support int input.
# => ╭─[entry #3:1:5]
# => 1 │ 1 | zip [2]
# => · ─┬─
# => · ╰── command doesn't support int input
# => ╰────
echo 1 | zip [2]
# => Error: nu:🐚:only_supports_this_input_type
# =>
# => × Input type not supported.
# => ╭─[entry #14:2:6]
# => 2 │ echo 1 | zip [2]
# => · ┬ ─┬─
# => · │ ╰── only list<any> and range input data is supported
# => · ╰── input type: int
# => ╰────
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
**Breaking change**: The type of a command's input is now checked
against the input/output types of that command at run-time. While these
errors should mostly be caught at parse-time, in cases where they can't
be detected at parse-time they will be caught at run-time instead. This
applies to both internal commands and custom commands.
Example function and corresponding parse-time error (same before and
after PR):
```nushell
def foo []: int -> nothing {
print $"my cool int is ($in)"
}
1 | foo
# => my cool int is 1
"evil string" | foo
# => Error: nu::parser::input_type_mismatch
# =>
# => × Command does not support string input.
# => ╭─[entry #16:1:17]
# => 1 │ "evil string" | foo
# => · ─┬─
# => · ╰── command doesn't support string input
# => ╰────
# =>
```
Before:
```nu
echo "evil string" | foo
# => my cool int is evil string
```
After:
```nu
echo "evil string" | foo
# => Error: nu:🐚:only_supports_this_input_type
# =>
# => × Input type not supported.
# => ╭─[entry #17:1:6]
# => 1 │ echo "evil string" | foo
# => · ──────┬────── ─┬─
# => · │ ╰── only int input data is supported
# => · ╰── input type: string
# => ╰────
```
Known affected internal commands which erroneously accepted any type:
* `str join`
* `zip`
* `reduce`
# 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.
-->
* Play whack-a-mole with the commands and scripts this will inevitably
break
<!--
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.
-->
#14528 mentioned that trying to `open` a file in a directory where you
don't have read access results in a "file not found" error. I
investigated the error and could find the root issue in the
`nu_engine::glob_from` function. It uses `std::path::Path::canonicalize`
some layers down and that may return an `std::io::Error`. All these
errors were handled as "directory not found" which will be translated to
"file not found" in the `open` command. To fix this, I handled the
`PermssionDenied` error kind of the io error and passed that down. Now
trying to `open` a file from a directory with no permissions returns a
"permission denied" error.
Before/After:
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
That error is fixed, so correct error message.
# 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.
-->
fixes#14528
# Description
Currently the step size of range values are discarded when converting to
nuon. This PR fixes that and makes `to nuon | from nuon` round trips
work.
# User-Facing Changes
`to nuon` conversion of `range` values now include the step size
# Tests + Formatting
Added some additional tests to cover inclusive/exclusive integer/float
and step size cases.
# Description
Fix cursor panic when handling size zero in binary viewer. Previously,
the cursor would panic
with arithmetic overflow when handling size 0. This PR fixes this by
using `saturating_sub`
to safely handle the edge case of size 0.
Fixes#14589
# User-Facing Changes
- Fixed panic when viewing very small binary inputs in the explore
command (when using `0x[f] | explore`)
# Tests + Formatting
Added tests to verify:
- Cursor handling of size 0
- Safe movement operations with size 0
- Edge case handling with size 1
✅ Verified all checks pass:
- `cargo fmt --all -- --check`
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used`
- `cargo test --package nu-explore --lib cursor`
# Description
Currently, if a custom completer returns a record containing an
`options` field, but these options don't specify `case_sensitive`,
`case_sensitive` will be true. This PR instead makes the default value
whatever the user specified in `$env.config.completions.case_sensitive`.
The match algorithm option already does this. `positional` is also
inherited from the global config, although user's can't actually specify
that one themselves in `$env.config` (I'm planning on getting rid of
`positional` in a separate PR).
# User-Facing Changes
For those making custom completions, if they need matching to be done
case-sensitively and:
- their completer returns a record rather than a list,
- and the record contains an `options` field,
- and the `options` field is a record,
- and the record doesn't contain a `case_sensitive` option,
then they will need to specify `case_sensitive: true` in their custom
completer's options. Otherwise, if the user sets
`$env.config.completions.case_sensitive = false`, their custom completer
will also use case-insensitive matching.
Others shouldn't have to make any changes.
# Tests + Formatting
Updated tests to check if `case_sensitive`. Basically rewrote them,
actually. I figured it'd be better to make a single helper function that
takes completer options and completion suggestions and generates a
completer from that rather than having multiple fixtures providing
different completers.
# After Submitting
Probably needs to be noted in the release notes, but I don't think the
[docs](https://www.nushell.sh/book/custom_completions.html#options-for-custom-completions)
need to be updated.
# Description
This PR introduces a switch `--serialize` that allows serializing of
types that cannot be deserialized. Right now it only serializes closures
as strings in `to toml`, `to json`, `to nuon`, `to text`, some indirect
`to html` and `to yaml`.
A lot of the changes are just weaving the engine_state through calling
functions and the rest is just repetitive way of getting the closure
block span and grabbing the span's text.
In places where it has to report `<Closure 123>` I changed it to
`closure_123`. It always seemed like the `<>` were not very nushell-y.
This is still a breaking change.
I think this could also help with systematic translation of old config
to new config file.
# 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 fixes a problem with `stor reset`. That problem was that it
called drop_all_tables which just iterated through the tables and
dropped them one by one. This works as long as there are no foreign keys
or if the tables are dropped in the "right" order. It doesn't work in
most cases since you have to know what order to drop tables in. So, this
PR turns off foreign key constraints, then drops all the tables, then
turns the foreign key constraints back on, which seems to work well...
so far. :)
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
Adds some doccomments to some of the methods in `engine_state.rs` and
`state_working_set.rs`. Also grouped together some of the `find` methods
in `engine_state.rs`, but didn't do so in `state_working_set.rs` since
they seem to already be grouped according to decl/overlay/module.
Follow-up to #14490.
# User-Facing Changes
None
# Tests + Formatting
N/A
# After Submitting
N/A
# Description
Fixes: #13158
To fix the issue for auto-cd feature, just need to use
`EngineState::cwd` instead of `nu_engine::env::current_dir_str`
# User-Facing Changes
## Before
```shell
> cd ~
> ln -s /tmp test_link; cd test_link
> ..
> $env.PWD
/
```
## After
```shell
> cd ~
> ln -s /tmp test_link; cd test_link
> ..
> $env.PWD # it should output home directory.
```
# Tests + Formatting
Update a test under `auto_cd_symlink`
fixes#14664
# Description
Now,
```nu
"aaa" | save -f ..
```
returns correct error message on windows.
Note that the fix introduces a TOCTOU problem, which only effects the
error message. It won't break any workload.
# User-Facing Changes
The fix won't break any workload.
# Tests + Formatting
I have run tests **only on windows**.
# After Submitting
The fix doesn't need to change documentation.
<!--
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.
-->
I just noticed that #14758 adds an extra newline when
`$env.config.table.show_empty = false`. This PR makes sure the
placeholder text is non-empty before adding the newline.
Before #14758:
```nushell
$env.config.table.show_empty = false
print ([]) text
# => text
echo []
```
Before PR:
```nushell
$env.config.table.show_empty = false
print ([]) text
# =>
# => text
echo []
# =>
```
After PR:
```nushell
$env.config.table.show_empty = false
print ([]) text
# => text
echo []
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
None, fix to #14758 which has not been included in a release
# 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.
-->
N/A
# Description
Small, backwards compatible enhancements to the standard library.
# User-Facing Changes
- changed `iter find`, `iter find-index`: Only consume the input stream
up to the first match.
- added `log set-level`: a small convenience command for setting the log
level
- added `$null_device`: `null-device` as a const variable, would allow
conditional sourcing if #13872 is fixed
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# 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
Prevents ndots from being expanded if they are prefixed with `./`, as
the agreed resolution to #13303. Only applies to externals, mirroring
the fix from #13218.
I did
[attempt](https://github.com/132ikl/nushell/tree/internal-ndots-attempt)
to apply the fix for internal commands as well, but it seems like the
path is expanded too aggressively and I haven't investigated it further
yet. `./...` gets normalized into `<pwd>/./...`, which gets normalized
into `<pwd>/...` before being handed to `expand_ndots`, and at that
point it just looks like a normal n-dots so we can't tell we shouldn't
expand.
(Fixes#13303)
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* N-dots are no longer expanded to external command calls when prefixed
with `./`.
# 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 tests to prevent regression.
- 🟢 `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.
-->
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.
-->
Adds a newline to the empty list output. Fixes#14748.
This does not affect the `[empty list]` text output in the REPL, just
the `print` output (to be honest, I'm not certain why, but I'm guessing
the REPL was adding an extra newline somewhere to compensate). The
`bytes.push('\n')` replicates the code from the below
`convert_table_to_output` function, which is bypassed for empty lists.
Before:
```nushell
[]
# => ╭────────────╮
# => │ empty list │
# => ╰────────────╯
print ([]) text
# => ╭────────────╮
# => │ empty list │
# => ╰────────────╯text
```
After:
```nushell
[]
# => ╭────────────╮
# => │ empty list │
# => ╰────────────╯
print ([]) text
# => ╭────────────╮
# => │ empty list │
# => ╰────────────╯
# => text
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Fixes "empty list" placeholder text output when using the `print`
command
# 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.
-->
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.
-->
Changes the `Value` variant match arm of `PipelineData::into_value` to
use the internal `Value`'s span instead of the span passed in by the
user. This aligns more closely with the `ListStream` and `ByteStream`
match arms, which already use their internal span, and allows errors to
provide better diagnostics since the span information doesn't get lost
when `into_value` is called. At the suggestion of @cptpiepmatz, if the
`Value` has `Span::unknown` for some reason, then we replace the
`Value`'s span with the passed in span.
Before:
```nushell
{} | get foo bar
# => Error: nu:🐚:column_not_found
# =>
# => × Cannot find column 'foo'
# => ╭─[entry #43:2:6]
# => 2 │ {} | get foo bar
# => · ─┬─ ─┬─
# => · │ ╰── cannot find column 'foo'
# => · ╰── value originates here
# => ╰────
```
After:
```nushell
{} | get foo bar
# => Error: nu:🐚:column_not_found
# =>
# => × Cannot find column 'foo'
# => ╭─[entry #2:2:1]
# => 2 │ {} | get foo bar
# => · ─┬ ─┬─
# => · │ ╰── cannot find column 'foo'
# => · ╰── value originates here
# => ╰────
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Some errors may have more accurate info about where the value
originates from
# 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.
-->
N/A
In #14249, `config reset` wasn't updated to use the scaffold config files, so running `config reset` would accidentally reset the user's config to the internal defaults. This PR updates it to use the
scaffold files.
fixes : #13729
During dot expansion, the "parent" was added even if it was after the
root (`/../../`).
Added additional check that skips appending elements to the path
representation if the parent folder is the root folder.
<!--
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 replaces `ropey` with `lsp-textdocument` for easier utf16
position handling.
As a side effect, if fixes the following crashing bug:
1. create a `foo.nu` file with errors in it
2. in `bar.nu`, add code `use foo.nu *`
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* <s>Diagnostics are now triggered only with document open/save, that's
my personal preference. Changing back to previous behavior is easy if
you guys have other concerns.</s>
* UTF-8 position encoding is not supported by lsp-textdocument, but
that's not an issue, since the previous utf-8 ropey implementation is
buggy when used in real scenarios in a text editor.
# 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
> ```
-->
No new tests added, removed some utf-8 related ones.
# 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.
-->
Makes `get` const
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
`get` is now a const command.
# 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.
-->
N/A
# Description
A follow-on to #14727:
* Instead of using `is-interactive` as the trigger for incrementing
`SHLVL`, this change puts the increment logic just before `run_repl()`
is called.
* Tests are changed to use `-e`
* Moves the `confirm_stdin_is_terminal()` call immediately **after** the
`prerun_cmd` (which executes `--execute (-e) <commandstring>`. The fact
that it was **before** that call seems to be a bug, since the error
message says *"or provide arguments to invoke a script"* even if
`--execute` was used. This change enables REPL testing using `--execute
(-e)`.
* Added a test to ensure `-c` does *not* increment SHLVL.
# User-Facing Changes
`$env.SHLVL` runs before the REPL is started, rather than when
`is-interactive`
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
N/A
# Description
I just spent way too long trying to get `nu --testbin nu_repl
<commands>` working. That's one argument that must be called as `nu
--testbin=nu_repl <commands>` due to its implementation. This PR simply
adds a comment in `main()` noting that, hoping it will save someone else
some time in the future ;-)
# User-Facing Changes
None
# Tests + Formatting
N/A
# 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.
-->
I realized that the `into bool` command somehow implements a conversion
into a boolean value which was very similar to my implementation of
~`Value::as_env_bool`~ `Value::coerce_bool`. To streamline that behavior
a bit, I replaced most of the implementation of `into bool` with my
~`Value::as_env_bool`~ `Value::coerce_bool` method.
Also I added a new flag called `--relaxed` which lets the command behave
more closely to the ~`Value::as_env_bool`~ `Value::coerce_bool` method
as it allows null values and is more loose to strings. ~Which now begs
the question, should I rename `Value::as_env_bool` just to
`Value::coerce_bool` which would fit the `Value::coerce_str` method
name?~ (Renamed that.)
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
The `into bool` command behaves the same but with `--relaxed` you can
also throw a `null` or some more strings at it which makes it more
ergonomic for env conversions.
# 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
> ```
-->
I added some more tests to see that the strict handling works and added
some more examples to the command to showcase the `--relaxed` flag which
also gets tested.
- 🟢 `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.
-->
@Bahex mentioned in #14704 that it broke the zoxide script, this PR
should help to fix the issue.
Tests for #14707 are causing hangs which are preventing `toolkit test`
from completing on some systems. This appears to be due to the use of
`-i` to force interactive mode, which is required in order to update the
`SHLVL`. Both tests are likely attempting to acquire the terminal at the
same time, and one is hanging as a result.
This is a temporary fix which runs both of these tests sequentially.
It's temporary because we need to find a solution which doesn't use
`-i`, since any other future `-it` test will cause the same situation
again.
# Description
Adds a user-level (non-vendor) autoload directory:
```
($nu.default-config-dir)/autoload
```
Currently this is the only directory. We can consider adding others if
needed.
Related: As a separate PR, I'm going to try to restore the ability to
set `$env.NU_AUTOLOAD_DIRS` during startup.
# User-Facing Changes
Files in `$nu.default-config-dir/autoload` will be autoload at startup.
These files will be loaded after any vendor autoloads, so that a user
can override the vendor settings.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
TODO; add a `$nu.user-autoload-dirs` constant.
Doc updates
# Description
Takes advantage of #14591 to remove the now-necessary calls to
`convert_env_values()` that I added in #14249. The function is now just
called once to convert `PATH`.
Also removed the Windows-build-time checks for `ensure_path`, since
previous case-insensitivity fixes make this unnecessary as well.
# User-Facing Changes
None - #14591 now handles conversion 'on-demand'.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# 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.
-->
I tried to setup a multiline prompt like this.
<img width="175" alt="スクリーンショット 2024-12-15 17 45 06"
src="https://github.com/user-attachments/assets/8d00a203-b341-45ce-8427-b4d5a9d3d7c3"
/>
But when I set PROMT_COMMAND like this,
```nu
$env.PROMPT_COMMAND = {|| $"(ansi reset)(ansi magenta)(date now | format date "%Y-%m-%dT%H:%M:%S%z")\n(pwd)\n" }
```
The result is like this, due to dropping `\n` and `\r` on
`prompt_update.rs`.
<img width="185" alt="スクリーンショット 2024-12-15 17 54 21"
src="https://github.com/user-attachments/assets/5ead998e-6f87-479f-b2de-e267f0cc3acd"
/>
Currently, adding two newlines can detour the drop.
I think this drop newline makes little sense, so I removed it on this
PR.
If you don't like it, feel free to close it.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Trailing newline of PROMPT_COMMAND is not dropped anymore.
# 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
> ```
-->
This is a subtle change just on prompt string, so I think particular
test is not so necessary.
# 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.
-->
As far as I read
https://www.nushell.sh/book/coloring_and_theming.html#prompt-configuration-and-coloring
, the behavior seems undocumented.
# Description
This PR removes the old `touch` command in favor of the uutils/coreutils
implementation of `touch`, which we integrated in 0.101 (#11817).
It turns out that in `utouch`, the `--no-deref`/`-s` wasn't working, and
the issue had gone undetected because I accidentally made the test for
that use `touch` rather than `utouch`. This has been fixed now.
# User-Facing Changes
Our old `touch` command didn't have anything that the new uutils-based
command doesn't, and the uutils-based command actually has a little more
functionality. So nothing using `touch` should break.
Scripts using `utouch` will have to use `touch` now, but given that
`utouch` has been around for less than 2 months, I assume people haven't
really been using it.
# Tests + Formatting
The utouch tests seem to have everything from the old touch tests, so I
deleted the old touch tests.
# After Submitting
This will need to be mentioned in the release notes.
# Description
These changes resolve#13623 where globs are not handled by `utouch`.
# User-Facing Changes
- Glob patterns passed to `utouch` will be resolved to all individual
files that match the pattern. For example, running `utouch *.txt` in a
directory that already has `file1.txt` and `file2.txt` is the same thing
as running `utouch file1.txt file2.txt`. All flags such as `-a`, `-m`
and `-c` will be respected.
- If a glob pattern is provided to `utouch` and doesn't match any files,
a file will be created with the literal name of the glob pattern. This
only applies to Linux/MacOS because Windows forbids creating file names
with restricted characters (see [naming a file
docs](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file))
---------
Co-authored-by: Henry Jetmundsen <hjetmundsen@atlassian.com>
# Description
Adds an `is_glob` function to the nu-glob crate that takes a string
pattern and returns whether or not it's a glob that would be expanded by
nu-glob. Right now, this just means checking if it contains `*`, `?`, or
`[`.
Previously, this same code was duplicated in the following places:
- `ls`: Determining whether to read a folder's contents or expand a glob
- `run_external.rs` in nu-command: Arguments to externals only have
n-dots and tilde expansion applied if they weren't globs
- `glob_from` in nu-engine:
- `glob_from` can get the prefix in a simpler way for non-globs
- If the canonical path for a non-glob path contains glob
metacharacters, it needs to be escaped
- `completion_common.rs` in nu-cli: File/folder completions containing
glob metacharacters need to be wrapped in quotes
All of these locations can use `nu_glob::is_glob` now instead of rolling
their own checks. This does mean that nu-cli now has a dependency on
nu-glob.
# User-Facing Changes
Users of nu-glob will now be able to check if a given pattern is a glob
expanded by nu-glob.
For users of Nushell, completion suggestions for files containing `]`
will no longer be wrapped in quotes if they contain no other glob
metacharacters. This is because unmatched `]`s are ignored by nu-glob,
but we used to consider such file completions contaminated anyway.
# Tests + Formatting
This is a very basic function, so I just added some doctests.
# After Submitting
This is meant to be used in
https://github.com/nushell/nushell/pull/14674.
# Description
We removed the regex crate long ago but there were a few instances where
we could not remove it because fancy-regex did not have a split/splitn,
and maybe other functions. Those functions now exist in the latest
fancy-regex crate so we can now remove it.
# 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 tries to improve a few error messages.
### 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.
-->
# Description
Rework of #14570, fixing #14567.
`exec` will decrement `SHLVL` env value before passing it to target
executable (in interactive mode).
(Same as last pr, but this time there's no wrong change to current
working code)
Two `SHLVL` related tests were also added this time.
<!--
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.
-->
The `Value::coerce_str` method weirdly doesn't allow coercing boolean
values into strings while commands like `true | into string` work
without issues. So I added that.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
This is technically a breaking change if a nushell library user depended
on the fact that boolean values weren't coerceable to strings. But I
doubt that really.
# 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`
Following #14700 we should make sure more folks are aware that you
shouldn't use `internal_span` outside of `Value` or core protocol/engine
internals.
By making it a doccomment maybe a few folks see the text in the lsp
hover etc.
# Description
Remove usages of `internal_span` in matches and initializers. I think
this should be the last of the usages, meaning `internal_span` can
finally be refactored out of `Value`(!?)
# Description
The docs reference "insert into" for the "delete" command.
# User-Facing Changes
N/A
# Tests + Formatting
I don't know of any tests for docs.
<!--
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
N/A
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
# Description
Conforming the examples in the README documentation to match the new
example formatting suggested in
https://github.com/nushell/nushell.github.io/issues/1684.
# User-Facing Changes
Examples no longer have a prompt indicator, and example results are now
inside of commend blocks. This should improve the ability for users to
test out the examples when exploring nushell for the first time.
# Tests + Formatting
No tests have been added as this is purely a documentation change.
<!--
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 should fix the currently broken standard library tests pipeline
by force installing nushell.
# 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
`into bits` is a bad name because it is not a traditional type cast to a
`bits` type like all the other `into` commands.
Instead it is a pretty printer generating `string` type output. Thus the
correct bucket is `format` and its subcommands.
# User-Facing Changes
`into bits` will raise a `DeprecatedWarning` suggesting the move to
`format bits`
`into bits` can be removed in `0.103.0`
# Tests + Formatting
All tests that relied on `into bits` have been updated to `format bits`
With this comes a new `unicode-width` as I remember there was some issue
with `ratatui`.
And a bit of refactorings which are ment to reduce code lines while not
breaking anything.
Not yet complete, I think I'll try to improve some more places,
just wanted to trigger CI 😄
And yessssssssss we have a new `unicode-width` but I sort of doubtful,
I mean the original issue with emojie.
I think it may require an additional "clean" call.
I am just saying I was not testing it with that case of complex emojies.
---------
Signed-off-by: Maxim Zhiburt <zhiburt@gmail.com>
# Description
This PR goes along with the recent changes by @cptpiepmatz for
[auto-color](https://github.com/nushell/nushell/pull/14647) and
[evaluation of
auto-color](https://github.com/nushell/nushell/pull/14683) which also
looks at env vars along with config settings to determine when it's
appropriate to show ansi coloring since it's more complicated than just
reading a setting or an env var.
# 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.
-->
In #14647 I added the option `"auto"` to be a valid option for
`$env.config.use_ansi_coloring`. That improves the decision making
whether ansi colors should be used or not but that makes it hard for
custom commands to respect that value as the config might now be a
non-boolean value. To retrieve that evaluated value I added a new
command called `config use-colors` that returns an evaluated boolean
that may be used to decide if colors should be used or not.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Scripts that previously just checked `$env.config.use_ansi_coloring`
should now use `config use-colors` for their color decision making.
# 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
> ```
-->
This PR essentially only runs `UseAnsiColoring::get`, and that is highly
tested in the #14647, so I don't think this needs further testing.
- 🟢 `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.
-->
I'm not sure if we have any docs about that ansi coloring setup. If we
have, we should update these.
# Description
These changes fix#13275 where a slash is appended to completions of
symlinks pointing to directories.
# User-Facing Changes
The `/` character will no longer be appended to completions of symlinks.
Co-authored-by: Henry Jetmundsen <jet@henrys-mbp-2.lan>
<!--
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.
-->
In this PR I continued the idea of #11494, it added an `auto` option to
the ansi coloring config option, I did this too but in a more simple
approach.
So I added a new enum `UseAnsiColoring` with the three values `True`,
`False` and `Auto`. When that value is set to `auto`, the default value,
it will use `std::io::stdout().is_terminal()` to decided whether to use
ansi coloring. This allows to dynamically decide whether to print ansi
color codes or not, [cargo does it the same
way](652623b779/src/bin/cargo/main.rs (L72)).
`True` and `False` act as overrides to the `is_terminal` check. So with
that PR it is possible to force ansi colors on the `table` command or
automatically remove them from the miette errors if no terminal is used.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Terminal users shouldn't be affected by this change as the default value
was `true` and `is_terminal` returns for terminals `true` (duh).
Non-terminal users, that use `nu` in some embedded way or the engine
implemented in some other way (like my jupyter kernel) will now have by
default no ansi coloring and need to enable it manually if their
environment allows it.
# 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
> ```
-->
The test for fancy errors expected ansi codes, since tests aren't run
"in terminal", the ansi codes got stripped away.
I added a line that forced ansi colors above it. I'm not sure if that
should be the case or if we should test against no ansi colors.
- 🟢 `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.
-->
This should resolve#11464 and partially #11847. This also closes
#11494.
Fixes#12627
# User-Facing Changes
Under FreeBSD, `cp` no longer errors with "--reflink is only supported
on
linux and macOS".
# Tests
The `commands::ucp` tests now pass on a FreeBSD 14.2 machine with ZFS.
# Description
Following up for issue comment:
https://github.com/nushell/nushell/pull/14407#issuecomment-2532343036
> it looks like it just hangs when it's actually counting things
I noticed that `du` command collects output internally, so it doesn't
streaming.
This pr is trying to make it streaming
# User-Facing Changes
NaN
# Tests + Formatting
NaN
- this PR should close#14514
# Description
Makes updates to `$env.ENV_CONVERSIONS` take effect immediately.
# User-Facing Changes
No breaking change, `$env.ENV_CONVERSIONS` can be set and its effect
used in the same file.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
# Description
Adds:
```nushell
$env.config.show_banner = "short"
```
This will display *only* the startup time. That was the only information
from the banner that the user couldn't possibly include in their own
config/banner (since it is `-1ns` during startup). This allows one to
create their own banner and yet still show the startup time.
Example (can be a file named `banner.nu` in autoloads:
```nushell
$env.config.show_banner = "short"
let ver = (version)
print $"(ansi blue_bold)Nushell Release:(ansi reset) ($ver.version) \(($ver.build_os)\)"
```
---
`true` and `false` settings continue to work as they do today. `true` is
still the default.
# User-Facing Changes
New configuration option:
```nushell
$env.config.show_banner = "short"
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
◼️ Update doc
◼️ Update `doc_config.nu`
Closes#6174
# Description
This PR aims to improve the performance of `ls` within large
directories. `ls` now delegates the metadata collection to
a thread in its thread pool.
Before:
Now:
# User-Facing Changes
If an error occurs while file metadata is being collected in another
thread, the `ls` command now notifies the user about this error by
sending an error value through a channel (which then gets collected into
an iterator and shown to the user later on).
However, if an error occurs _while_ sending this error value to the
channel (i.e the resulting value iterator has been dropped), then the
user is not notified of this error. I think this behavior is acceptable,
since behavior only occurs when the `ls` pipeline has been dropped and
the user is no longer interested in output from `ls`.
# Tests + Formatting
I do not know if it is a good idea to test this performance with
`timeit`, since it can be unreliable.
This PR should close
1. #10327
1. #13667
1. #13810
1. #14129
# Description
This got reverted https://github.com/nushell/nushell/pull/14606 because
the previous changes only considered space a whitespace and forgot about
tabs. I now added a check for any whitespace, even if it is only those
two that would be relevant.
The added test failed before the changes.
For `#` to start a comment, then it either need to be the first
character of the token or prefixed with ` ` (space).
So now you can do this:
```
~/Projects/nushell> 1..10 | each {echo test#testing } 12/05/2024 05:37:19 PM
╭───┬──────────────╮
│ 0 │ test#testing │
│ 1 │ test#testing │
│ 2 │ test#testing │
│ 3 │ test#testing │
│ 4 │ test#testing │
│ 5 │ test#testing │
│ 6 │ test#testing │
│ 7 │ test#testing │
│ 8 │ test#testing │
│ 9 │ test#testing │
╰───┴──────────────╯
```
# User-Facing Changes
It is a breaking change if anyone expected comments to start in the
middle of a string without any prefixing ` ` (space).
# Tests + Formatting
Did all:
- `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
# After Submitting
I cant see that I need to update anything in [the
documentation](https://github.com/nushell/nushell.github.io) but please
point me in the direction if there is anything.
Related #10708
# Description
Add `bytes split` command. `bytes split` splits its input on the
provided separator on binary values _and_ binary streams without
collecting. The separator can be a multiple character string or multiple
byte binary.
It can be used when neither `split row` (not streaming over raw input)
nor `lines` (streaming, but can only split on newlines) is right.
The backing iterator implemented in this PR, `SplitRead`, can be used to
implement a streaming `split row` in the future.
# User-Facing Changes
`bytes split` command added, which can be used to split binary values
and raw streams using a separator.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
Mention in release notes.
# Description
Adds support for `Value::Binary` and `ByteStream` inputs to `chunks`.
In case of `ByteStream`, stream is not collected, and chunked as it
comes.
This works:
```nushell
open --raw /dev/urandom | chunks 4 | take 4
```
# User-Facing Changes
`chunks` can now be used on binary values and streams.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# 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.
-->
In v0.101.0 we got `config nu --default` and `config nu --doc` which
return a default config. That default config is valid `.nu`, so it
should have the metadata for it. We defined our MIME types [here in the
docs](https://www.nushell.sh/lang-guide/chapters/mime_types.html), so I
added that.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Tools that read the metadata can now also detect that these two commands
are nushell scripts.
# 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.
-->
# Description
Because `and` and `or` are short-circuiting operations in Nushell, they
must be compiled to a sequence that avoids evaluating the RHS if the LHS
is already sufficient to determine the output - i.e., `false` for `and`
and `true` for `or`. I initially implemented this with `branch-if`
instructions, simply returning the RHS if it needed to be evaluated, and
returning the short-circuited boolean value if it did not.
Example for `$a and $b`:
```
0: load-variable %0, var 999 "$a"
1: branch-if %0, 3
2: jump 5
3: load-variable %0, var 1000 "$b" # label(0), from(1:)
4: jump 6
5: load-literal %0, bool(false) # label(1), from(2:)
6: span %0 # label(2), from(4:)
7: return %0
```
Unfortunately, this broke polars, because using `and`/`or` on custom
values is perfectly valid and they're allowed to define that behavior
differently, and the polars plugin uses this for boolean masks. But
without using the `binary-op` instruction, that custom behavior is never
invoked. Additionally, `branch-if` requires a boolean, and custom values
are not booleans. This changes the IR to the following, using the
`match` instruction to check for the specific short-circuit value
instead, and still invoking `binary-op` otherwise:
```
0: load-variable %0, var 125 "$a"
1: match (false), %0, 4
2: load-variable %1, var 124 "$b"
3: binary-op %0, Boolean(And), %1
4: span %0 # label(0), from(1:)
5: return %0
```
I've also renamed `Pattern::Value` to `Pattern::Expression` and added a
proper `Pattern::Value` variant that actually contains a `Value`
instead. I'm still hoping to remove `Pattern::Expression` eventually,
because it's kind of a hack - we don't actually evaluate the expression,
we just match it against a few cases specifically for pattern matching,
and it's one of the cases where AST leaks into IR and I want to remove
all of those cases, because AST should not leak into IR.
Fixes#14518
# User-Facing Changes
- `and` and `or` now support custom values again.
- the IR is actually a little bit cleaner, though it may be a bit
slower; `match` is more complex.
# Tests + Formatting
The existing tests pass, but I didn't add anything new. Unfortunately I
don't think there's anything built-in to trigger this, but maybe some
testcases could be added to polars to test it.
# Description
The `std::time::Instant` type panics in the WASM context. To prevent
this, I replaced all uses of `std::time::Instant` in WASM-relevant
crates with `web_time::Instant`. This ensures commands using `Instant`
work in WASM without issues. For non-WASM targets, `web-time` simply
reexports `std::time`, so this change doesn’t affect regular builds
([docs](https://docs.rs/web-time/latest/web_time/)).
To ensure future code doesn't reintroduce `std::time::Instant` in WASM
contexts, I added a `clippy wasm` command to the toolkit. This runs
`cargo clippy` with a `clippy.toml` configured to disallow
`std::time::Instant`. Since `web-time` aliases `std::time` by default,
the `clippy.toml` is stored in `clippy/wasm` and is only loaded when
targeting WASM. I also added a new CI job that tests this too.
# User-Facing Changes
None.
r#"Use this command instead of checking `$env.config.use_ansi_coloring` to properly handle the "auto" setting, including environment variables that influence its behavior."#
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.
