# Description
The `job unfreeze` command relies on the `os` feature of the
`nu-protocol` crate, which means that `nu-command` doesn't compile with
`--no-default-features`. This PR gates `job unfreeze` behind
`nu-command`'s `os` feature to avoid this.
No user-facing changes, no tests needed.
# Description
Follow-up to #15272, changing default to disallow DTD as discussed.
Especially applicable for the `http get` case.
# User-Facing Changes
Changes behavior introduced in #15272, so release notes need to be
updated to reflect this
Fixes messed ansi escapes in hover text (manpage):
<img width="392" alt="image"
src="https://github.com/user-attachments/assets/37c16520-d499-4079-93d9-0eccd1cfa8de"
/>
# Description
That bug is introduced in #15115.
Also refactored the hover related code to a separate file, just like
other features.
# User-Facing Changes
# Tests + Formatting
# After Submitting
# Description
`into string` should not modify input strings (even with the
`--group-digits` flag). It's a conversion command, not a formatting
command.
# User-Facing Changes
- For strings, the same behavior from 0.102.0 is preserved.
- Errors are no longer turned into strings, but rather they are returned
as is.
# After Submitting
Create a `format int` and/or `format float` command and so that the
`--group-digits` flag can be transferred to one of those commands.
# Description
Before this PR, `to msgpack`/`to msgpackz` and `to json` serialize
closures as `nil`/`null` respectively, when the `--serialize` option
isn't passed. This PR makes it an error to serialize closures to msgpack
or JSON without the `--serialize` flag, which is the behavior of `to
nuon`.
This PR also adds the `--serialize` flag to `to msgpack`.
This PR also changes `to nuon` and `to json` to return an error if they
cannot find the block contents of a closure, rather than serializing an
empty string or an error string, respectively. This behavior is
replicated for `to msgpack`.
It also changes `to nuon`'s error message for serializing closures
without `--serialize` to be the same as the new errors for `to json` and
`to msgpack`.
# User-Facing Changes
* Add `--serialize` flag to `to msgpack`, similar to the `--serialize`
flag for `to nuon` and `to json`.
* Serializing closures to JSON or msgpack without `--serialize`
Partially fixes#11738
<!--
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.
-->
Update `toolkit.nu` add `nu_plugin_polars` plugin for build and install
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
`toolkit install --all` and `toolkit build --all` will have
`nu_plugin_polars` included
While inspecting the Windows specific code of `ls` for #15311 I stumbled
upon an unrelated issue in the alternate metadata gathering on Windows
(added by #5703).
The handle created by performing `FindFirstFileW` was never closed,
leading to a potential leak. Fixed by running `FindClose` as soon as the
operation succeeds.
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew#remarks
# Description
This PR removes the mimalloc allocator due to run-away memory leaks
recently found.
closes#15311
# 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
Found inconsistent behaviors of `directory_completion` and
`file_completion`, https://github.com/nushell/nushell/issues/13951https://github.com/nushell/reedline/pull/886
Also there're failing cases with such file names/dir names `foo(`,
`foo{`, `foo[`.
I think it doesn't harm to be more conservative at adding quotes, even
if it might be unnecessary for paired names like `foo{}`.
# User-Facing Changes
# Tests + Formatting
Adjusted
# After Submitting
Came from [this
discussion](https://discord.com/channels/601130461678272522/1348791953784836147/1349699872059691038)
on discord with @fdncred
# Description
Small refactoring where I rename commands from "SubCommand" to its
proper name. Motivations: better clarity (although subjective), better
searchable, consistency.
The only commands I didn't touch were "split list" and "ansi gradient"
because of name clashes.
# User-Facing Changes
None
# Tests + Formatting
cargo fmt and clippy OK
# After Submitting
nothing required
# Description
Adds a new `--empty/-e` flag to the `default` command.
# User-Facing Changes
Before:
```nushell
$env.FOO = ""
$env.FOO = $env.FOO? | default bar
$env.FOO
# => Empty string
```
After:
```nushell
$env.FOO = ""
$env.FOO = $env.FOO? | default -e bar
$env.FOO
# => bar
```
* Uses `val.is_empty`, which means that empty lists and records are also
replaced
* Empty values in tables (with a column specifier) are also replaced.
# Tests + Formatting
7 tests added and 1 updated + 1 new example
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
N/A
# fixes https://github.com/nushell/nushell/issues/15281
# Description
Provides the ability read dataframes with Categorical and Enum data
The ability to write Categorical and Enum data will provided in a future
PR
# Description
Follow up to https://github.com/nushell/nushell/pull/14634
# User-Facing Changes
`into bits` will be gone for good.
Use it under the new name `format bits`
## Note
Can be removed ahead of the `0.103.0` release as it was deprecated with
`0.102.0`
# Description
Follow up to https://github.com/nushell/nushell/pull/14875
# User-Facing Changes
`fmt` will be gone for good.
Use it under the new name `format number`
## Note
Can be removed ahead of the `0.103.0` release as it was deprecated with
`0.102.0`
Fixes#15077
# Description
Symlinks are currently not shown in directory completions. #14667
modified completions so that symlinks wouldn't be suggested with
trailing slashes, but it did this by treating symlinks as files. This PR
includes symlinks to directories when completing directories, but still
suggests them without trailing slashes.
# User-Facing Changes
Directory completions will once again include symlinks.
# 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 allows `from xml` to parse XML documents with [document type
declarations](https://en.wikipedia.org/wiki/Document_type_declaration)
by default. This is especially notable since many HTML documents start
with `<!DOCTYPE html>`, and `roxmltree` should be able to parse some
simple HTML documents. The security concerns with DTDs are [XXE
attacks](https://en.wikipedia.org/wiki/XML_external_entity_attack), and
[exponential entity expansion
attacks](https://en.wikipedia.org/wiki/Billion_laughs_attack).
`roxmltree` [doesn't
support](d2c7801624/src/tokenizer.rs (L535-L547))
external entities (it parses them, but doesn't do anything with them),
so it is not vulnerable to XXE attacks. Additionally, `roxmltree` has
[some
safeguards](d2c7801624/src/parse.rs (L424-L452))
in place to prevent exponential entity expansion, so enabling DTDs by
default is relatively safe. The worst case is no worse than running
`loop {}`, so I think allowing DTDs by default is best, and DTDs can
still be disabled with `--disallow-dtd` if needed.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Allows `from xml` to parse XML documents with [document type
declarations](https://en.wikipedia.org/wiki/Document_type_declaration)
by default, and adds a `--disallow-dtd` flag to disallow parsing
documents with DTDs.
This PR also improves the errors in `from xml` by pointing at the issue
in the XML source. Example:
```
$ open --raw foo.xml | from xml
Error: × Failed to parse XML
╭─[2:7]
1 │ <html>
2 │ <p<>hi</p>
· ▲
· ╰── Unexpected character <, expected a whitespace
3 │ </html>
╰────
```
# 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
Fix failing test by ignoring the local offset when converting times, but still displaying the
resulting date in the local timezone (including applicable DST offset).
# User-Facing Changes
Fix: Unix Epochs now convert consistently regardless of whether DST is
in effect in the local timezone or not.
# Description
In the [Nushell core team meeting
2025-02-19](https://hackmd.io/r3V83bMdQqKMwFxz90nBDg?view) we decided to
run tests on the beta toolchain to contribute to the Rust project as a
whole. These tests do not need to succeed for us to go further but allow
us to investigate if the beta toolchain broke something.
# User-Facing Changes
None.
# Tests + Formatting
Just a new workflow.
# After Submitting
Watch out for modification of this file changing the notified person
### Description
Fixes issue #15135
Result
Also this works with other commands: min, max, sum, product, avg...
### User-Facing Changes
Error is returned, instead of console completely blocked and having to
be killed
I chose "Incorrect value", because commands accept inputs of range type,
just cannot work with unbounded ranges.
### Tests + Formatting
- ran cargo fmt, clippy
- added tests
# Description
The upstream crate fixed a bug of position calc, which made some extra
checking in lsp unnecessary.
Also moved some follow-up fixing of #15238 from #15270 here, as it has
something to do with previous position calc bug.
# User-Facing Changes
# Tests + Formatting
Adjusted
# After Submitting
# Description
Continuation of #15271. This PR adds the
`$env.config.filesize.show_unit` option to allow the ability to omit the
filesize unit. Useful if `$env.config.filesize.unit` is set to a fixed
unit, and you don't want the same unit repeated over and over.
# User-Facing Changes
- Adds the `$env.config.filesize.show_unit` option.
# Description
Commands and other pieces of code using `$env.config.format.filesize` to
format filesizes now respect the system locale when formatting the
numeric portion of a file size.
# User-Facing Changes
- System locale is respected when using `$env.config.format.filesize` to
format file sizes.
- Formatting a file size with a binary unit is now exact for large file
sizes and units.
- The output of `to text` is no longer dependent on the config.
# Description
This PR allows the `into string` command to pass the `--group-digits`
flag which already existed in this code but was hard coded to `false`.
Now you can do things like
```nushell
❯ 1234567890 | into string --group-digits
1,234,567,890
❯ ls | into string size --group-digits | last 5
╭─#─┬────────name─────────┬─type─┬──size──┬───modified───╮
│ 0 │ README.md │ file │ 12,606 │ 4 weeks ago │
│ 1 │ rust-toolchain.toml │ file │ 1,125 │ 2 weeks ago │
│ 2 │ SECURITY.md │ file │ 2,712 │ 7 months ago │
│ 3 │ toolkit.nu │ file │ 21,929 │ 2 months ago │
│ 4 │ typos.toml │ file │ 542 │ 7 months ago │
╰─#─┴────────name─────────┴─type─┴──size──┴───modified───╯
❯ "12345" | into string --group-digits
12,345
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
Fixes this:
<div class="Box p-3 markdown-body f5 mb-4">
<h2 dir="auto">Vulnerabilities</h2>
<h3 dir="auto"><a
href="https://rustsec.org/advisories/RUSTSEC-2025-0009.html"
rel="nofollow">RUSTSEC-2025-0009</a></h3>
<blockquote>
<p dir="auto">Some AES functions may panic when overflow checking is
enabled.</p>
</blockquote>
<markdown-accessiblity-table data-catalyst=""><table role="table">
<thead>
<tr>
<th>Details</th>
<th></th>
</tr>
</thead>
<tbody>
<tr>
<td>Package</td>
<td><code class="notranslate">ring</code></td>
</tr>
<tr>
<td>Version</td>
<td><code class="notranslate">0.17.8</code></td>
</tr>
<tr>
<td>URL</td>
<td><a
href="https://github.com/briansmith/ring/blob/main/RELEASES.md#version-01712-2025-03-05">https://github.com/briansmith/ring/blob/main/RELEASES.md#version-01712-2025-03-05</a></td>
</tr>
<tr>
<td>Date</td>
<td>2025-03-06</td>
</tr>
<tr>
<td>Patched versions</td>
<td><code class="notranslate">>=0.17.12</code></td>
</tr>
</tbody>
</table></markdown-accessiblity-table>
<p dir="auto"><code
class="notranslate">ring::aead::quic::HeaderProtectionKey::new_mask()</code>
may panic when overflow<br>
checking is enabled. In the QUIC protocol, an attacker can induce this
panic by<br>
sending a specially-crafted packet. Even unintentionally it is likely to
occur<br>
in 1 out of every 2**32 packets sent and/or received.</p>
<p dir="auto">On 64-bit targets operations using <code
class="notranslate">ring::aead::{AES_128_GCM, AES_256_GCM}</code>
may<br>
panic when overflow checking is enabled, when encrypting/decrypting
approximately<br>
68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk.
Protocols<br>
like TLS and SSH are not affected by this because those protocols break
large<br>
amounts of data into small chunks. Similarly, most applications will
not<br>
attempt to encrypt/decrypt 64GB of data in one chunk.</p>
<p dir="auto">Overflow checking is not enabled in release mode by
default, but<br>
<code class="notranslate">RUSTFLAGS=&quot;-C
overflow-checks&quot;</code> or <code
class="notranslate">overflow-checks = true</code> in the Cargo.toml<br>
profile can override this. Overflow checking is usually enabled by
default in<br>
debug mode.</p>
</div>
# Description
As stated in the title, when pressing ctrl-z, I sometimes feel confused
because I return to the REPL without any message. I don't know if the
process has been killed or suspended.
This PR aims to add a message to notify the user that the process has
been frozen.
# User-Facing Changes
After pressing `ctrl-z`. A message will be printed in repl.
# Tests + Formatting
NaN
# After Submitting
NaN
# Description
This fixes#15240, which can be closed after merge.
# User-Facing Changes
- user get now use `to yml` -> exactly the same as `to yaml`
# Tests + Formatting
Cargo fmt and clippy 🆗
I added a test in the only place I could find where `to yaml` was
already tested.
I didn't see the `save.rs::convert_to_extension` function tested
anywhere, but maybe I missed it.
# After Submitting
Not sure this needs an update on the documentation ❓ What do you
suggest?
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
This PR implements the changes proposed in #15112 without any breaking
changes. Should close#15112 post the review.
# Description
Added functionality to generate `uuid` versions 1, 3, 4, 5, 7 instead of
just the version 4.
- Users can now add a `-v n` flag to specify the version of uuid they
want to generate and it maintains backward compatibility by returning a
v4 uuid by default if no flags are passed.
- Versions 3 and 5 have the additional but required namespace (`-s`) and
name (`-n`) arguments too. Version 1 requires a mac address (`-m`).
# User-Facing Changes
- Added support for uuid versions 1, 3, 5 and 7.
- For v3 and v5, the namespace and name arguments are required and hence
there will be an error if those are not passed. Similarly the mac
address for v1.
- Full backward compatibility by setting v4 as default.
# Tests + Formatting
Tests added:
in `nu-command::commands::random`
- generates_valid_uuid4_by_default
- generates_valid_uuid1
- generates_valid_uuid3_with_namespace_and_name
- generates_valid_uuid4
- generates_valid_uuid5_with_namespace_and_name
- generates_valid_uuid7
Fixes#15243
# Description
As noted in #15243, a record with more characters after it (e.g.,
`{a:b}/`) will cause an OOM due to an infinite loop, introduced by
#15023. This happens because the entire string `{a:b}/` is lexed as one
token and passed to `parse_record`, where it repeatedly lexes until it
hits the closing `}`. This PR detects such extra characters and reports
an error.
# User-Facing Changes
`{a:b}/` and other such constructions will no longer cause infinite
loops. Before #15023, you would've seen an "Unclosed delimiter" error
message, but this PR changes that to "Invalid characters."
```
Error: nu::parser::extra_token_after_closing_delimiter
× Invalid characters after closing delimiter
╭─[entry #5:1:7]
1 │ {a:b}/
· ┬
· ╰── invalid characters
╰────
help: Try removing them.
```
# Tests + Formatting
# After Submitting
# Description
Fixes: #14540
The change is similar to #14101
User input can be a directory, in this case, we need to use the return
value of find_in_dirs_env carefully, so in case, I renamed
maybe_file_path to maybe_file_path_or_dir to emphasize it.
# User-Facing Changes
NaN
# Tests + Formatting
Added 2 test cases
# After Submitting
This PR (based on #15249 and #15248 because it mentions them) adds extra
documentation to the main polars command outlining the main datatypes
that are used by the plugin. The lack of a description of the types
involved in `polars xxx` commands was quite confusing to me when I
started using the plugin and this is a first try improving it.
I didn't find a better place but please let me know what you think.
solution for #15242
adds "And"
```
~/Projects/nushell> [[a, b]; [1., 2.], [3.,3.], [4., 6.]] | polars into-df | polars filter (((polars col a) > 2) and ((polars col b) < 5))
╭───┬──────┬──────╮
│ # │ a │ b │
├───┼──────┼──────┤
│ 0 │ 3.00 │ 3.00 │
╰───┴──────┴──────╯
```
adds "Or"
```
~/Projects/nushell> [[a, b]; [1., 2.], [3.,3.], [4., 6.]] | polars into-df | polars filter (((polars col a) > 7) or ((polars col b) > 5))
╭───┬──────┬──────╮
│ # │ a │ b │
├───┼──────┼──────┤
│ 0 │ 4.00 │ 6.00 │
╰───┴──────┴──────╯
```
but not (yet) xor because polars doesn't have a direct expression for
logical_xor
```
~/Projects/nushell> [[a, b]; [1., 2.], [3.,3.], [4., 6.]] | polars into-df | polars filter (((polars col a) > 7) xor ((polars col b) > 5))
Error: nu:🐚:operator_unsupported_type
× The 'xor' operator does not work on values of type 'NuExpression'.
╭─[entry #5:1:94]
1 │ [[a, b]; [1., 2.], [3.,3.], [4., 6.]] | polars into-df | polars filter (((polars col a) > 7) xor ((polars col b) > 5))
· ─┬─┬
· │ ╰── NuExpression
· ╰── does not support 'NuExpression'
╰────
```
Co-authored-by: Jack Wright <56345+ayax79@users.noreply.github.com>
# Description
Append space if marked as required.
Aligned behavior as the REPL completion.
# User-Facing Changes
# Tests + Formatting
Adjusted
# After Submitting
Fixes#14971, fixes#15229
# User-Facing Changes
Fixes a panic when variable data is accessed after invalid usage of the
`|` separator, which made it impossible to type certain match arms:
```nushell
> match $in { 1 |
Error: x Main thread panicked.
|-> at crates/nu-protocol/src/engine/state_delta.rs💯14
`-> internal error: missing required scope frame
```
# Description
Removes duplicative calls to `exit_scope` from an inner loop when `|`
parse errors are encountered. The outer loop creates and exits scopes
for each match arm.
# Description
Fixes issue #15215
# User-Facing Changes
Change in help msg in "to json" command with -r flag
# Tests + Formatting
cargo fmt 🆗
# After Submitting
Doc for that is generated from code I think, so 🆗
# Description
To check for missing parameters
<img width="417" alt="image"
src="https://github.com/user-attachments/assets/5e2a8356-5fd9-4d15-8ae6-08321f9d6e0b"
/>
# User-Facing Changes
For other languages, the help request can be triggered by the `(`
character of the function call.
Editors like nvim refuse to set the trigger character to space, and
space is probably way too common for that.
So this kind of request has to be triggered manually for now.
example of nvim config:
```lua
vim.api.nvim_create_autocmd("FileType", {
pattern = "nu",
callback = function(event)
vim.bo[event.buf].commentstring = "# %s"
vim.api.nvim_buf_set_keymap(event.buf, "i", "<C-f>", "", {
callback = function()
vim.lsp.buf.signature_help()
end,
})
end,
})
```
# Tests + Formatting
+2
# 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.
-->
Add ansi codes to move cursor position: `ansi cursor_left`, `ansi
cursor_right`, `ansi cursor_up`, `ansi cursor_down`
Why I add these? I'm trying to add a spinner to the message end for a
long running task, just to find that I need to move the cursor left to
make it work as expected: `with-progress 'Waiting for the task to
finish' { sleep 10sec }`
```nu
def with-progress [
message: string, # Message to display
action: closure, # Action to perform
--success: string, # Success message
--error: string # Error message
] {
print -n $'($message) '
# ASCII spinner frames
let frames = ['⠋', '⠙', '⠹', '⠸', '⠼', '⠴', '⠦', '⠧', '⠇', '⠏']
# Start the spinner in the background
let spinner_pid = job spawn {
mut i = 0
print -n (ansi cursor_off)
loop {
print -n (ansi cursor_left)
print -n ($frames | get $i)
sleep 100ms
$i = ($i + 1) mod ($frames | length)
}
}
# Run the action and capture result
let result = try {
do $action
{ success: true }
} catch {
{ success: false }
}
# Stop the spinner
job kill $spinner_pid
print "\r \r"
# Show appropriate message
if $result.success {
print ($success | default '✓ Done!')
} else {
print ($error | default '✗ Failed!')
exit 1
}
}
```
# 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 a table contains an empty list or record in one column and both column
and -e flags are used, then skip that row.
`compact -e` now skips empty values in a column where as before they were
ignored. Example:
```nu
[["a", "b"]; ["c", "d"], ["h", []]]
| compact -e b
```
before
```plain
# a b
────────────────────────
0 c d
1 h [list 0 items]
```
after
```plain
# a b
───────────
0 c d
```
# Description
Improves the completeness of operator completions.
Check the new test cases for details.
# User-Facing Changes
# Tests + Formatting
+4
# After Submitting
# Description
This PR tries to update the EditCommands and ReedlineEvents by adding
missing items and ordering them to the same order that the reedline enum
has them listed.
@sholderbach When you have time, would you mind looking at this please.
I left some TODOs because I wasn't sure how to implement them. I also
guessed at some of the other implementations. I don't use vim much so
I'm not really sure how these are supposed to act. I was really just
trying to fill in the blanks.
# User-Facing Changes
Closes#15167
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
---------
Co-authored-by: sholderbach <sholderbach@users.noreply.github.com>
Bumps [rust-embed](https://github.com/pyros2097/rust-embed) from 8.5.0
to 8.6.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/pyrossh/rust-embed/blob/master/changelog.md">rust-embed's
changelog</a>.</em></p>
<blockquote>
<h2>[8.6.0] - 2025-02-25</h2>
<ul>
<li>Update include-flate to 0.3 <a
href="https://redirect.github.com/pyrossh/rust-embed/pull/246">#246</a>.
Thanks to <a href="https://github.com/krant">krant</a></li>
<li>refactor: remove redundant reference and closure <a
href="https://redirect.github.com/pyrossh/rust-embed/pull/250">#250</a>.
Thanks to <a href="https://github.com/hamirmahal">hamirmahal</a></li>
<li>refactor: replace map().unwrap_or_else(). <a
href="https://redirect.github.com/pyrossh/rust-embed/pull/255">#250</a>.
Thanks to <a href="https://github.com/hamirmahal">hamirmahal</a></li>
<li>Compatible with Axum 0.7.9 <a
href="https://redirect.github.com/pyrossh/rust-embed/pull/253">#253</a>.
Thanks to <a href="https://github.com/wkmyws">wkmyws</a></li>
<li>Add allow_missing option to derive macro <a
href="https://redirect.github.com/pyrossh/rust-embed/pull/256">#256</a>.
Thanks to <a href="https://github.com/lirannl">lirannl</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/pyros2097/rust-embed/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 adds extra_description stating what syntax query json is with
links. It also adds some examples since query json was written before
examples existed for plugins.
# 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.
-->
This is the most recent version
Deduplicates the `crossterm` dependency, brings `itertools` in line with
the majority of dependencies.
In the fight against compile times this sadly introduces a
proc-macro-crate for writing proc-macros (`darling`) as a transitive
dependency. So may not lead to a compile time improvement (or could make
it even slightly worse)
Observation: Cargo changed the `Cargo.lock` file version when running
this. (this should still be the specified toolchain, so don't expect a
risk of locking out the expected `cargo` versions)
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.29.5 to
1.29.10.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/crate-ci/typos/releases">crate-ci/typos's
releases</a>.</em></p>
<blockquote>
<h2>v1.29.10</h2>
<h2>[1.29.10] - 2025-02-25</h2>
<h3>Fixes</h3>
<ul>
<li>Also correct <code>contaminent</code> as
<code>contaminant</code></li>
</ul>
<h2>v1.29.9</h2>
<h2>[1.29.9] - 2025-02-20</h2>
<h3>Fixes</h3>
<ul>
<li><em>(action)</em> Correctly get binary for some aarch64 systems</li>
</ul>
<h2>v1.29.8</h2>
<h2>[1.29.8] - 2025-02-19</h2>
<h3>Features</h3>
<ul>
<li>Attempt to build Linux aarch64 binaries</li>
</ul>
<h2>v1.29.7</h2>
<h2>[1.29.7] - 2025-02-13</h2>
<h3>Fixes</h3>
<ul>
<li>Don't correct <code>implementors</code></li>
</ul>
<h2>v1.29.6</h2>
<h2>[1.29.6] - 2025-02-13</h2>
<h3>Features</h3>
<ul>
<li>Updated the dictionary with the <a
href="https://redirect.github.com/crate-ci/typos/issues/1200">January
2025</a> changes</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's
changelog</a>.</em></p>
<blockquote>
<h2>[1.29.10] - 2025-02-25</h2>
<h3>Fixes</h3>
<ul>
<li>Also correct <code>contaminent</code> as
<code>contaminant</code></li>
</ul>
<h2>[1.29.9] - 2025-02-20</h2>
<h3>Fixes</h3>
<ul>
<li><em>(action)</em> Correctly get binary for some aarch64 systems</li>
</ul>
<h2>[1.29.8] - 2025-02-19</h2>
<h3>Features</h3>
<ul>
<li>Attempt to build Linux aarch64 binaries</li>
</ul>
<h2>[1.29.7] - 2025-02-13</h2>
<h3>Fixes</h3>
<ul>
<li>Don't correct <code>implementors</code></li>
</ul>
<h2>[1.29.6] - 2025-02-13</h2>
<h3>Features</h3>
<ul>
<li>Updated the dictionary with the <a
href="https://redirect.github.com/crate-ci/typos/issues/1200">January
2025</a> changes</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="db35ee91e8"><code>db35ee9</code></a>
chore: Release</li>
<li><a
href="9f43c4dbd2"><code>9f43c4d</code></a>
docs: Update changelog</li>
<li><a
href="a1da2ce137"><code>a1da2ce</code></a>
Merge pull request <a
href="https://redirect.github.com/crate-ci/typos/issues/1244">#1244</a>
from epage/containment</li>
<li><a
href="d74d5fd5ad"><code>d74d5fd</code></a>
Merge pull request <a
href="https://redirect.github.com/crate-ci/typos/issues/1243">#1243</a>
from epage/dict</li>
<li><a
href="fa6122604f"><code>fa61226</code></a>
refactor(dict): Drop a dict</li>
<li><a
href="6276d585f7"><code>6276d58</code></a>
fix(dict): Correct contaminents to another spelling</li>
<li><a
href="07c9e1f6fa"><code>07c9e1f</code></a>
chore(deps): Update Rust Stable to v1.85 (<a
href="https://redirect.github.com/crate-ci/typos/issues/1241">#1241</a>)</li>
<li><a
href="71643b1191"><code>71643b1</code></a>
Merge pull request <a
href="https://redirect.github.com/crate-ci/typos/issues/1240">#1240</a>
from szepeviktor/patch-1</li>
<li><a
href="931a5804a4"><code>931a580</code></a>
Fix typo in README</li>
<li><a
href="c5137fd6aa"><code>c5137fd</code></a>
refactor(action): Isolate unique parts</li>
<li>Additional commits viewable in <a
href="https://github.com/crate-ci/typos/compare/v1.29.5...v1.29.10">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 adds `polars str-strip-chars-end`
# User-Facing Changes
New function that can be used as follows:
```
~/Projects/nushell> [[text]; [hello!!!] [world!!!]] | polars into-df | polars select (polars col text | polars str-strip-chars-end "!") | polars collect
╭───┬───────╮
│ # │ text │
├───┼───────┤
│ 0 │ hello │
│ 1 │ world │
╰───┴───────╯
```
# Tests + Formatting
tests ran locally.
I ran the formatter.
# 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 is an attempt to improve the nushell situation with regard to issue
#247.
This PR implements:
- [X] spawning jobs: `job spawn { do_background_thing }`
Jobs will be implemented as threads and not forks, to maintain a
consistent behavior between unix and windows.
- [X] listing running jobs: `job list`
This should allow users to list what background tasks they currently
have running.
- [X] killing jobs: `job kill <id>`
- [X] interupting nushell code in the job's background thread
- [X] interrupting the job's currently-running process, if any.
Things that should be taken into consideration for implementation:
- [X] (unix-only) Handling `TSTP` signals while executing code and
turning the current program into a background job, and unfreezing them
in foreground `job unfreeze`.
- [X] Ensuring processes spawned by background jobs get distinct process
groups from the nushell shell itself
This PR originally aimed to implement some of the following, but it is
probably ideal to be left for another PR (scope creep)
- Disowning external process jobs (`job dispatch`)
- Inter job communication (`job send/recv`)
Roadblocks encountered so far:
- Nushell does some weird terminal sequence magics which make so that
when a background process or thread prints something to stderr and the
prompt is idle, the stderr output ends up showing up weirdly
# Description
Hot fix of a newly introduced bug by #15086.
Forgot to trim the line str according to the expression span, which will
disable external command completions in many cases.
Also adds the suggestion kind to external commands, for lsp
visualization.
# User-Facing Changes
Before:
<img width="246" alt="image"
src="https://github.com/user-attachments/assets/c62904f6-0dd7-4368-8f0b-aacd6fe590f0"
/>
After:
<img width="291" alt="image"
src="https://github.com/user-attachments/assets/76316649-956f-4828-94cb-41f79d5f94f7"
/>
I find it better to visually distinguish externals from internals, so
`function` for internals and `interface` for externals.
But it's arguably not the best option.
# Tests + Formatting
test case adjusted
# After Submitting
# Description
It is a rework of https://github.com/nushell/nushell.github.io/pull/1819
So, I was wasting time looking for equivalent of `filter_map` in Nu,
unaware that `each` already has it. This PR is to make it clear in the
documentation, saving other user's time.
# User-Facing Changes
No
# Tests + Formatting
No
# After Submitting
No
# Description
Fixes#14852
As the completion rules are somehow intertwined between internals and
externals,
this PR is relatively messy, and has larger probability to break things,
@fdncred @ysthakur @sholderbach
But I strongly believe this is a better direction to go. Edge cases
should be easier to fix in the dedicated branches.
There're no flattened expression based completion rules left.
# User-Facing Changes
# Tests + Formatting
+7
# After Submitting
---------
Co-authored-by: Yash Thakur <45539777+ysthakur@users.noreply.github.com>
- this PR addresses most of the points in #13153
# Description
- make `split list` support streaming
- **[BREAKING CHANGE]** if the input is split on consecutive items, the
empty lists between those items are preserved.
e.g. `[1 1 0 0 3 3 0 4 4] | split list 0` == `[[1 1] [] [2 2] [3 3]]`
- accept a closure as argument, the closure is called for each item, and
if it returns `true` the list is split on that item
- added `--split` flag, which allows keeping the separator items.
`--split=after` splits the list *after* the separator and
`--split=before` splits the list *before* the separator.
`--split=on` is the default behavior where the separator is lost
# User-Facing Changes
`split list`:
- keeps empty sublists
- allows using a closure to determine items to split on
- allows keeping the separator items with `--split=after` and
`--split=before`
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
This PR fixes#15131 by allowing the `insert` and `upsert` commands to
create lists where they may be expected based on the cell path provided.
For example, the below would have previously thrown an error, but now
creates lists and list elements where necessary
<img width="173" alt="Screenshot 2025-02-17 at 2 46 12 AM"
src="https://github.com/user-attachments/assets/6d680e7e-6268-42ed-a037-a0795014a7e0"
/>
<img width="200" alt="Screenshot 2025-02-17 at 2 46 16 AM"
src="https://github.com/user-attachments/assets/50d0e8eb-aabb-49fe-b961-5f7489fdc993"
/>
<img width="284" alt="Screenshot 2025-02-17 at 2 45 43 AM"
src="https://github.com/user-attachments/assets/242a2ec6-7e8f-4a51-92ce-9d5ec10f867f"
/>
# User-Facing Changes
This change removes errors that were previously raised by
`insert_data_at_cell_path` and `upsert_data_at_cell_path`. If one of
these commands encountered an unknown cell path in cases such as these,
it would either raise a "Not a list value" as the list index is used on
a record:
<img width="326" alt="Screenshot 2025-02-17 at 2 46 43 AM"
src="https://github.com/user-attachments/assets/39b9b006-388b-49b3-82a0-8cc9b739feaa"
/>
Or a "Row number too large" when required to create a new list element
along the way:
<img width="475" alt="Screenshot 2025-02-17 at 2 46 51 AM"
src="https://github.com/user-attachments/assets/007d1268-7d26-42aa-9bf5-d54c0abf4058"
/>
But both now succeed, which seems to be the intention as it is in parity
with record behavior. Any consumers depending on this specific behavior
will see these errors subside.
This change also includes the static method
`Value::with_data_at_cell_path` that creates a value with a given nested
value at a given cell path, creating records or lists based on the path
member type.
# Tests + Formatting
In addition to unit tests for the altered behavior, both affected
user-facing commands (`insert` and `upsert`) gained a new command
example to both explain and test this change at the user level.
<img width="382" alt="Screenshot 2025-02-17 at 2 29 26 AM"
src="https://github.com/user-attachments/assets/e6973640-3ce6-4ea7-9ba5-d256fe5cb38b"
/>
Note: A single test did fail locally, due to my config directory
differing from expected, but works where this variable is unset
(`with-env { XDG_CONFIG_HOME: null } {cargo test}`):
```
---- repl::test_config_path::test_default_config_path stdout ----
thread 'repl::test_config_path::test_default_config_path' panicked at tests/repl/test_config_path.rs:101:5:
assertion failed: `(left == right)`
Diff < left / right > :
<[home_dir]/Library/Application Support/nushell
>[home_dir]/.config/nushell
```
In this PR, the two new variants for `ErrorKind`, `FileNotFound`
and `DirectoryNotFound` with a nice `not_found_as` method for the
`ErrorKind` to easily specify the `NotFound` errors. I also updated some
places where I could of think of with these new variants and the message
for `NotFound` is no longer "Entity not found" but "Not found" to be
less strange.
closes#15142closes#15055
This PR always sets a fresh `PROMPT_COMMAND` and `PROMPT_COMMAND_RIGHT`
during startup in `default_env.nu`. This is a more "sensible default",
and can then be overridden with user config later in the startup.
<!--
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
Closes#13765
Transpose now checks if the input consists entirely of records before
doing its things, which is fine since it already `.collects()` all of
its input already.
<!--
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
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
Adds `rejects_non_table_stream_input` test to cover regressions.
<!--
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 bumps the rust toolchain to 1.83.0 and fixes a clippy lint. We
do this because Rust 1.85.0 was released today, and we try and stay 2
versions behind.
# 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
Resolves#15070 by removing the `BACKTRACE` message from all Nushell
(non-panic) errors. This was added in #14945 and is useful for
debugging, but not all that helpful to the typical shell user,
especially since most shell errors won't have a backtrace anyway.
At some point it would be nice to display this message only when there
*is* a backtrace available.
# User-Facing Changes
Error messages will be more concise.
# Tests + Formatting
Updated tests.
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
We should include information in the *"Custom Commands"* chapter of the
documentation on how to enable this for debugging.
adds feature spécified in bracoxide#6
```
$ echo {01..10}
01 02 03 04 05 06 07 08 09 10
$ echo {1..010}
001 002 003 004 005 006 007 008 009 010
```
I'm going to update the examples, but I'm currently on mobile. Will land
in a couple of days.
# Description
This PR updates nushell to the latest reedline commit
[4ca1ed9](4ca1ed960f)
# 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 adds the `@category` attribute to nushell for use with custom
commands.
### Example Code
```nushell
# Some example with category
@category "math"
@search-terms "addition"
@example "add two numbers together" {
blah 5 6
} --result 11
def blah [
a: int # First number to add
b: int # Second number to add
] {
$a + $b
}
```
#### Source & Help
```nushell
❯ source blah.nu
❯ help blah
Some example with category
Search terms: addition
Usage:
> blah <a> <b>
Flags:
-h, --help: Display the help message for this command
Parameters:
a <int>: First number to add
b <int>: Second number to add
Input/output types:
╭─#─┬─input─┬─output─╮
│ 0 │ any │ any │
╰───┴───────┴────────╯
Examples:
add two numbers together
> blah 5 6
11
```
#### Show the category
```nushell
❯ help commands | where name == blah
╭─#─┬─name─┬─category─┬─command_type─┬────────description─────────┬─────params─────┬──input_output──┬─search_terms─┬─is_const─╮
│ 0 │ blah │ math │ custom │ Some example with category │ [table 3 rows] │ [list 0 items] │ addition │ false │
╰───┴──────┴──────────┴──────────────┴────────────────────────────┴────────────────┴────────────────┴──────────────┴──────────╯
```
# 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.
-->
/cc @Bahex
The test added in #15115 fails on systems using later versions of `man`
(2.13.0 triggers the issue, at least). This updates the test to ignore
formatting characters.
Thanks to @fdncred and @blindFS for the debugging assistance.
The banner will now use three new `$env.config.color_config` settings:
- `banner_foreground`: The primary color of the banner text
- `banner_highlight1`: Used for the first set of highlights, e.g.,
`Nushell`, `nu`, `GitHub`, et. al
- `banner_highlight2`: Used for the second set of highlights, e.g.
`Discord`, `Documentation`, et. al.
If the settings above are not defined, `banner` continues to use the
default green/purple/foreground. However, two more lines use the
purple/highlight2 in order to give more separation and consistency to
the colorization.
# Description
There has been multiple instances of users being unable to discover that
`chunks` can be used with binary data.
This should make it easier for users to discover that (using `help -f`).
# User-Facing Changes
Help text of `chunks` updated as mentioned above.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
Should we consider mentioning commands that can work with binary input
(first, take, chunks, etc) in the help text for `bytes`?
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
Update some comments and fix potential security issue:
SQL Injection in DELETE statements: The code constructs SQL queries by
interpolating the $key variable directly into the string. If a key
contains malicious input could lead to SQL injection. Need to use
parameterized queries or escaping.
Manually added bindings take priority to the vi-mode state machine in
reedline thus this addition blocked the use of `f/`/`t/` etc.
Partial revert of #14908
Addresses #15096 with a temporary fix. The full solution of that should
resolve it on the reedline side so you can have both the search option
and the availability of `/` in normal mode bindings
# Description
`overlay use` now imports constants exported from modules, just like
`use`.
```nushell
# foo.nu
export const a = 1
export const b = 2
```
- `overlay use foo.nu` being equivalent to `use foo.nu *` and exposing
constants `$a = 1` and `$b = 2`
- `overlay use foo.nu -p` being equivalent to `use foo.nu` and exposing
the constant `$foo = {a: 1, b: 2}`
# User-Facing Changes
`overlay use` now imports constants just like `use`.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
# Description
This PR adds two new `ParseError` and `ShellError` cases for type errors
relating to operators.
- `OperatorUnsupportedType` is used when a type is not supported by an
operator in any way, shape, or form. E.g., `+` does not support `bool`.
- `OperatorIncompatibleTypes` is used when a operator is used with types
it supports, but the combination of types provided cannot be used
together. E.g., `filesize + duration` is not a valid combination.
The other preexisting error cases related to operators have been removed
and replaced with the new ones above. Namely:
- `ShellError::OperatorMismatch`
- `ShellError::UnsupportedOperator`
- `ParseError::UnsupportedOperationLHS`
- `ParseError::UnsupportedOperationRHS`
- `ParseError::UnsupportedOperationTernary`
# User-Facing Changes
- `help operators` now lists the precedence of `not` as 55 instead of 0
(above the other boolean operators). Fixes#13675.
- `math median` and `math mode` now ignore NaN values so that `[NaN NaN]
| math median` and `[NaN NaN] | math mode` no longer trigger a type
error. Instead, it's now an empty input error. Fixing this in earnest
can be left for a future PR.
- Comparisons with `nan` now return false instead of causing an error.
E.g., `1 == nan` is now `false`.
- All the operator type errors have been standardized and reworked. In
particular, they can now have a help message, which is currently used
for types errors relating to `++`.
```nu
[1] ++ 2
```
```
Error: nu::parser::operator_unsupported_type
× The '++' operator does not work on values of type 'int'.
╭─[entry #1:1:5]
1 │ [1] ++ 2
· ─┬ ┬
· │ ╰── int
· ╰── does not support 'int'
╰────
help: if you meant to append a value to a list or a record to a table, use the `append` command or wrap the value in a list. For example: `$list ++ $value` should be
`$list ++ [$value]` or `$list | append $value`.
```
- fixes#14559
# Description
Allow using `const` keyword in const contexts. The `run_const` body is
basically empty as the actual logic is already handled by the parser.
# User-Facing Changes
`const` keyword can now be used in `const` contexts.
# Tests + Formatting
I'll add some tests before marking this ready.
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
After #14906, the test runner was updated to use attributes, along with
the existing `std` modules. However, since that PR was started before
`std-rfc` was in main, it didn't include updates to those tests. Once
#14906 was merged, the `std-rfc` tests no longer ran in CI. This PR
updates the tests accordingly.
<!--
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 the usage of `proc-macro-error` with
`proc-macro-error2`. At the time of writing `nu-derive-value` this
wasn't an option, at least it wasn't clear that it is the direction to
go. This shouldn't change any of the usage of `nu-derive-value` in any
way but removes one security warning.
`proc-macro-error` depends on `syn 1`, that's why I initially had the
default features for `proc-macro-error` disabled. `proc-macro-error2`
uses `syn 2` as mostly everything. So we can use that.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Same interface, no 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`
The tests for `nu-derive-value` do not test spans, so maybe something
changed now but probably not.
# 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 still have `quickcheck` which depends on `syn 1` but it seems we need
that for `nu-cmd-lang`. Would be great if, in the future, we can get rid
of `syn 1` as that should improve build times a bit.
# Description
Zyphys found that when parsing `{...{}, ...{}, a: 1}`, the `a:` would be
considered one token, leading to a parse error ([Discord
message](https://discord.com/channels/601130461678272522/614593951969574961/1336762075535511573)).
This PR fixes that.
What would happen is that while getting tokens, the following would
happen in a loop:
1. Get the next two tokens while treating `:` as a special character (so
we get the next field key and a colon token)
2. Get the next token while not treating `:` as a special character (so
we get the next value)
I didn't update this when I added the spread operator. With `{...{},
...{}, a: 1}`, the first two tokens would be `...{}` and `...{}`, and
the next token would be `a:`. This PR changes this loop to first get a
single token, check if it's spreading a record, and move on if so.
Alternatives considered:
- Treat `:` as a special character when getting the value too. This
would simplify the loop greatly, but would mean you can't use colons in
values.
- Merge the loop for getting tokens and the loop for parsing those
tokens. I tried this, but it complicates things if you run into a syntax
error and want to create a garbage span going to the end of the record.
# User-Facing Changes
Nothing new
# Description
Close: #15083
This pr will set `pre` field of version to `Prerelease::EMPTY`, as
nushell does not require this level of checking currently.
# User-Facing Changes
NaN
# Tests + Formatting
Added 1 test
# After Submitting
NaN
# Description
Add custom command attributes.
- Attributes are placed before a command definition and start with a `@`
character.
- Attribute invocations consist of const command call. The command's
name must start with "attr ", but this prefix is not used in the
invocation.
- A command named `attr example` is invoked as an attribute as
`@example`
- Several built-in attribute commands are provided as part of this PR
- `attr example`: Attaches an example to the commands help text
```nushell
# Double numbers
@example "double an int" { 5 | double } --result 10
@example "double a float" { 0.5 | double } --result 1.0
def double []: [number -> number] {
$in * 2
}
```
- `attr search-terms`: Adds search terms to a command
- ~`attr env`: Equivalent to using `def --env`~
- ~`attr wrapped`: Equivalent to using `def --wrapped`~ shelved for
later discussion
- several testing related attributes in `std/testing`
- If an attribute has no internal/special purpose, it's stored as
command metadata that can be obtained with `scope commands`.
- This allows having attributes like `@test` which can be used by test
runners.
- Used the `@example` attribute for `std` examples.
- Updated the std tests and test runner to use `@test` attributes
- Added completions for attributes
# User-Facing Changes
Users can add examples to their own command definitions, and add other
arbitrary attributes.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
- Add documentation about the attribute syntax and built-in attributes
- `help attributes`
---------
Co-authored-by: 132ikl <132@ikl.sh>
# Description
Pre-cratification of `nu-command` we added tests that covered the whole
command set to ensure consistent documentation style choices and that
the search terms which are added are not uselessly redundant. These
tests are now moved into the suite of the main binary to truly cover all
commands.
- **Move parser quickcheck "fuzz" to `nu-cmd-lang`**
- **Factor out creation of full engine state for tests**
- **Move all-command tests to main context creation**
- **Fix all descriptions**
- **Fix search term duplicate**
# User-Facing Changes
As a result I had to fix a few command argument descriptions. (Doesn't
mean I fully stand behind this choice, but) positionals
(rest/required/optional) and top level descriptions should start with a
capital letter and end with a period. This is not enforced for flags.
# Tests + Formatting
Furthermore I moved our poor-peoples-fuzzer that runs in CI with
`quicktest` over the parser to `nu-cmd-lang` reducing its command set to
just the keywords (similar to
https://github.com/nushell/nushell/pull/15036). Thus this should also
run slightly faster (maybe a slight parallel build cost due to earlier
dependency on quicktest)
# Description
This PR makes `match` no longer run closures as if they were blocks.
This also allows returning closures from `match` without needing to wrap
in an outer subexpression or block.
Before PR:
```nushell
match 1 { _ => {|| print hi} }
# => hi
```
After PR:
```nushell
match 1 { _ => {|| print hi} }
# => closure_1090
```
# User-Facing Changes
* `match` no longer runs closures as if they were blocks
# Tests + Formatting
N/A
# After Submitting
N/A
# Description
The index in `explore --index` starting with 1 is inconsistent with rest
of nushell. Also it tripped me up a few times when I wanted to select a
row with `:nu get n`
# User-Facing Changes
Index in `explore --index` now starts with 0.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
# Description
Fixes: #15049
The error occurs when using an alias with a module prefix, it can
initially pass through alias checking, but if the alias leads to
commands which have side effects, it doesn't call these functions to
apply side effects.
This pr ensure that in such cases, nushell still calls
`parse_overlay_xxx` functions to apply the side effects.
I want to make my test easier to write, so this pr depends on
https://github.com/nushell/nushell/pull/15054.
# User-Facing Changes
The following code will no longer raise an error:
```
module inner {}
module spam { export alias b = overlay use inner }
use spam
spam b
```
# Tests + Formatting
Added 2 tests.
# After Submitting
NaN
# Description
Fixes: #15048
The issue is happened while `parse_export_in_block`, it makes a call to
`parse_internal_call`, which may be an error.
But in reality, these errors are not useful, all useful errors will be
generated by `parse_xxx` at the end of the function.
# User-Facing Changes
The following code should no longer raise error:
```
export alias a = overlay use
```
# Tests + Formatting
Added 1 test.
# After Submitting
NaN
# Description
fixes#14643 , as well as some nested cell path cases:
```nushell
let foo = {a: [1 {a: 1}]}
$foo.a.1.#<tab>
const bar = {a: 1, b: 2}
$bar.#<tab>
```
So my plan of the refactoring process is that:
1. gradually move those rules of flattened shapes into expression match
branches, until they are gone
2. keep each PR focused, easier to review and track.
# User-Facing Changes
# Tests + Formatting
+2
# After Submitting
Fixes#15061
# User-Facing Changes
Fixes panics when slicing empty input with inclusive ranges:
```nushell
> random binary 0 | bytes at 0..0
Error: x Main thread panicked.
|-> at crates/nu-protocol/src/value/range.rs:118:42
`-> attempt to subtract with overflow
```
# Description
Current CI tests `std-lib-and-python-virtualenv` using Nushell installed
with:
```
cargo install --path . --locked --no-default-features --force
```
However, this disables certain features that may be utilized in `std` or
(now) `std-rfc`; namely `stor` and `into sqlite`.
This PR simply removes the `--no-default-features` flag, which *should*
allow #15042 CI to complete successfully.
Historically, I believe that this was set up to mirror
[`pypa/virtualenv`
CI](https://github.com/pypa/virtualenv/pulls?q=is%3Apr+is%3Amerged+nushell).
However, with all Nushell binary builds now including these features, it
seems to me that a more accurate CI will test with default features. Let
me know if my understanding is off here, and we can look for
alternatives.
# User-Facing Changes
None
# Tests + Formatting
CI Update
# 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 #14968 I grepped the code for `IoError::new` calls with unknown
spans, but I forgot to also grep for
`IoError::new_with_additional_context`, so I missed some. Hopefullly
this is the last P.S. to #14968.
# 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
> ```
-->
- 🟢 `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 PR fixes one reported bug of recent lsp changes.
It exit unexpectedly with empty `root_dir` settings in neovim.
# User-Facing Changes
# Tests + Formatting
+1 test case
# After Submitting
Make sure that when creating a cherry-picked or otherwise diverging
patch release branch the final product still gets checked via CI before
a release is cut.
To trigger this patch release branches MUST follow the pattern:
`patch-release-*` (e.g. `patch-release-0.102.1`)
# Description
The parsing logic for several of our keywords is conditional on the
particular commands for those keywords being in scope:
942030199d/crates/nu-parser/src/parse_keywords.rs (L272-L279)
Thus the following involved parsing logic was not fuzzed by the existing
`parse` fuzz target so far.
This adds an additional fuzz target `parse_with_keywords` that loads the
commands from `nu-cmd-lang`. Those are primarily the keyword
implementations, thus the relevant code paths in the parser that depend
on those `DeclId`s and the potential const eval of `if` etc. get
unlocked.
The existing `parse` target is preserved if you have concerns about the
fuzzing breaking containment in some form due to those commands.
# Tests + Formatting
Found https://github.com/nushell/nushell/issues/14972 with this target
# Description
The `(version).build_os` variable inherits from `shadow_rs` `BUILD_OS`
which points to the OS on which the binary was built but does not
reflect the target if it was cross-compiled. We cross-compile several of
the targets for our binary releases. Thus the info in the banner was
misleading.
# User-Facing Changes
By changing to `build_target` the target triple is shown instead.
This is slightly more verbose but should also allow disambiguation
between the `musl` and `glibc` builds.
# Tests + Formatting
(-)
Fixes#15028
# Description
The current implementation of `into duration` uses bare pointer
arithmetic instead of wrapping one. This works fine on 64-bit platforms,
since the pointers don't take up all of the 64 bits, but fails on 32 bit
ones.
# Tests + Formatting
All of the affected tests pass on my end, but it's `x86_84`, so they
were also passing before that.
# Description
After this pr, nushell is able to raise errors with a backtrace, which
should make users easier to debug. To enable the feature, users need to
set env variable via `$env.NU_BACKTRACE = 1`. But yeah it might not work
perfectly, there are some corner cases which might not be handled.
I think it should close#13379 in another way.
### About the change
The implementation mostly contained with 2 parts:
1. introduce a new `ChainedError` struct as well as a new
`ShellError::ChainedError` variant. If `eval_instruction` returned an
error, it converts the error to `ShellError::ChainedError`.
`ChainedError` struct is responsable to display errors properly. It
needs to handle the following 2 cases:
- if we run a function which runs `error make` internally, it needs to
display the error itself along with caller span.
- if we run a `error make` directly, or some commands directly returns
an error, we just want nushell raise an error about `error make`.
2. Attach caller spans to `ListStream` and `ByteStream`, because they
are lazy streams, and *only* contains the span that runs it
directly(like `^false`, for example), so nushell needs to add all caller
spans to the stream.
For example: in `def a [] { ^false }; def b [] { a; 33 }; b`, when we
run `b`, which runs `a`, which runs `^false`, the `ByteStream` only
contains the span of `^false`, we need to make it contains the span of
`a`, so nushell is able to get all spans if something bad happened.
This behavior is happened after running `Instruction::Call`, if it
returns a `ByteStream` and `ListStream`, it will call `push_caller_span`
method to attach call spans.
# User-Facing Changes
It's better to demostrate how it works by examples, given the following
definition:
```nushell
> $env.NU_BACKTRACE = 1
> def a [x] { if $x == 3 { error make {msg: 'a custom error'}}}
> def a_2 [x] { if $x == 3 { ^false } else { $x } }
> def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } }
> def b [--list-stream --external] {
if $external == true {
# error with non-zero exit code, which is generated from external command.
a_2 1; a_2 3; a_2 2
} else if $list_stream == true {
# error generated by list-stream
a_3 1; a_3 3; a_3 2
} else {
# error generated by command directly
a 1; a 2; a 3
}
}
```
Run `b` directly shows the following error:
<details>
```nushell
Error: chained_error
× oops
╭─[entry #27:1:1]
1 │ b
· ┬
· ╰── error happened when running this
╰────
Error: chained_error
× oops
╭─[entry #26:10:19]
9 │ # error generated by command directly
10 │ a 1; a 2; a 3
· ┬
· ╰── error happened when running this
11 │ }
╰────
Error:
× a custom error
╭─[entry #6:1:26]
1 │ def a [x] { if $x == 3 { error make {msg: 'a custom error'}}}
· ─────┬────
· ╰── originates from here
╰────
```
</details>
Run `b --list-stream` shows the following error
<details>
```nushell
Error: chained_error
× oops
╭─[entry #28:1:1]
1 │ b --list-stream
· ┬
· ╰── error happened when running this
╰────
Error: nu:🐚:eval_block_with_input
× Eval block failed with pipeline input
╭─[entry #26:7:16]
6 │ # error generated by list-stream
7 │ a_3 1; a_3 3; a_3 2
· ─┬─
· ╰── source value
8 │ } else {
╰────
Error: nu:🐚:eval_block_with_input
× Eval block failed with pipeline input
╭─[entry #23:1:29]
1 │ def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } }
· ┬
· ╰── source value
╰────
Error:
× a custom error inside list stream
╭─[entry #23:1:44]
1 │ def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } }
· ─────┬────
· ╰── originates from here
╰────
```
</details>
Run `b --external` shows the following error:
<details>
```nushell
Error: chained_error
× oops
╭─[entry #29:1:1]
1 │ b --external
· ┬
· ╰── error happened when running this
╰────
Error: nu:🐚:eval_block_with_input
× Eval block failed with pipeline input
╭─[entry #26:4:16]
3 │ # error with non-zero exit code, which is generated from external command.
4 │ a_2 1; a_2 3; a_2 2
· ─┬─
· ╰── source value
5 │ } else if $list_stream == true {
╰────
Error: nu:🐚:non_zero_exit_code
× External command had a non-zero exit code
╭─[entry #7:1:29]
1 │ def a_2 [x] { if $x == 3 { ^false } else { $x } }
· ──┬──
· ╰── exited with code 1
╰────
```
</details>
It also added a message to guide the usage of NU_BACKTRACE, see the last
line in the following example:
```shell
ls asdfasd
Error: nu:🐚:io::not_found
× I/O error
╰─▶ × Entity not found
╭─[entry #17:1:4]
1 │ ls asdfasd
· ───┬───
· ╰── Entity not found
╰────
help: The error occurred at '/home/windsoilder/projects/nushell/asdfasd'
set the `NU_BACKTRACE=1` environment variable to display a backtrace.
```
# Tests + Formatting
Added some tests for the behavior.
# After Submitting
# Description
I have investigated all const commands and found that math log contains
some duplicate code, which can be eliminated by introducing a new helper
function. So this pr is going to do this
# User-Facing Changes
NaN
# Tests + Formatting
NaN
# After Submitting
NaN
# Description
Parquet, CSV, NDJSON, and Arrow files can be written to AWS S3 via
`polars save`. This mirrors the s3 functionality provided by `polars
open`.
```nushell
ls | polars into-df | polars save s3://my-bucket/test.parquet
```
# User-Facing Changes
- S3 urls are now supported by `polars save`
Closes#14993
<!--
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
New keybinding has been added to `explore`
<!-- 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
Make `echo` const.
- It's a very simple command, there is no reason for it to not be const.
- It's return type `any` is utilized in tests to type erase values, this
might be useful for testing const evaluation too.
- The upcoming custom command attribute feature can make use of it as a
stopgap replacement for `const def` commands.
# User-Facing Changes
`echo` can be used in const contexts.
# Tests + Formatting
# After Submitting
N/A
# Description
- Add keybinding for `/` when in vi normal mode which activates the
history menu.
- Make keybinding `mode` (`edit_mode`) case-insensitive.
This keybinding exists both in vim and GNU Readline (e.g. bash) when in
vi normal mode. The reason this keybinding is getting added here (and
not in `reedline`) is because it triggers the history menu, and should
only be defined when the history menu exists. Menus are defined
externally to `reedline`.
# User-Facing Changes
Added keybinding for `/` when in vi normal mode which activates the
history menu.
# 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
TODO: Update docs
# Description
As discussed
[here](https://github.com/nushell/nushell/pull/14856#issuecomment-2623393017)
and [here](https://github.com/nushell/nushell/discussions/14868).
I feel this method is generally better. As for the new-parser, we can
simply modify the implementation in `traverse.rs` to accommodate.
Next, I'm gonna overhaul the `Completer` trait, so before it gets really
messy, I' think this is the step to put this open for review so we can
check if I'm on track.
This PR closes#13897 (the `|` part)
# User-Facing Changes
# After Submitting
# Description
- Remove redundant fields from KnownExternal
- Command::extra_description and Command::search_terms using the
signature field
# User-Facing Changes
`extern` commands extra description is now shown in help text.
# 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.
-->
Adds search terms for hide and hide-env.
Rel: #15013
# 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.
-->
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.
@ -35,7 +34,7 @@ This project has reached a minimum-viable-product level of quality. Many people
The [Nushell book](https://www.nushell.sh/book/) is the primary source of Nushell documentation. You can find [a full list of Nu commands in the book](https://www.nushell.sh/commands/), and we have many examples of using Nu in our [cookbook](https://www.nushell.sh/cookbook/).
We're also active on [Discord](https://discord.gg/NtAbbGn) and [Twitter](https://twitter.com/nu_shell); come and chat with us!
We're also active on [Discord](https://discord.gg/NtAbbGn); come and chat with us!
## Installation
@ -95,44 +94,44 @@ Commands that work in the pipeline fit into one of three categories:
Commands are separated by the pipe symbol (`|`) to denote a pipeline flowing left to right.
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.
