Closes#14552
# Description
Implemented a new flag to the ```to md``` command to center specific
columns in Markdown table output using a list of CellPaths.
This enhances formatting control for users exporting tables to markdown.
## Example
For the table:
```shell
let t = version | select version build_time | transpose k v
```
```
╭───┬────────────┬────────────────────────────╮
│ # │ k │ v │
├───┼────────────┼────────────────────────────┤
│ 0 │ version │ 0.104.1 │
│ 1 │ build_time │ 2025-05-21 11:15:45 +01:00 │
╰───┴────────────┴────────────────────────────╯
```
Running ```$t | to md``` or ```$t | to md --pretty``` gives us,
respectively:
```
|k|v|
|-|-|
|version|0.104.1|
|build_time|2025-05-21 11:15:45 +01:00|
```
|k|v|
|-|-|
|version|0.104.1|
|build_time|2025-05-21 11:15:45 +01:00|
and
```
| k | v |
| ---------- | -------------------------- |
| version | 0.104.1 |
| build_time | 2025-05-21 11:15:45 +01:00 |
```
| k | v |
| ---------- | -------------------------- |
| version | 0.104.1 |
| build_time | 2025-05-21 11:15:45 +01:00 |
With the new ```center``` flag, when adding ```--center [v]``` to the
previous commands, we obtain, respectively:
```
|k|v|
|-|:-:|
|version|0.104.1|
|build_time|2025-05-21 11:15:45 +01:00|
```
|k|v|
|-|:-:|
|version|0.104.1|
|build_time|2025-05-21 11:15:45 +01:00|
and
```
| k | v |
| ---------- |:--------------------------:|
| version | 0.104.1 |
| build_time | 2025-05-21 11:15:45 +01:00 |
```
| k | v |
| ---------- |:--------------------------:|
| version | 0.104.1 |
| build_time | 2025-05-21 11:15:45 +01:00 |
The new ```center``` option, as demonstrated in the example, not only
formats the Markdown table to center columns but also, when paired with
```pretty```, it also centers the string values within those columns.
The logic works by extracting the column from the CellPath and applying
centering. So, ```--center [1.v]``` is also valid and centers the
```v``` column.
You can also specify multiple columns, for instance, ```--center [v
k]``` will center both columns in the example above.
# User-Facing Changes
The ```to md``` command will support column centering with the new
```center``` flag.
# Tests + Formatting
Added test cases to ensure correct behaviour.
fmt + clippy OK.
# After Submitting
The command documentation needs to be updated with the new ```center```
flag and an example.
Co-authored-by: Marco Cunha <marcomarquesdacunha@tecnico.ulisboa.pt>
Co-authored-by: Marco Cunha <marcomarquesdacunha@tecnico.ulisboa.pt>
<!--
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.
-->
Try to fix PAT issue of `winget` publish account, this change may make
publish with `nushell` account work
# Description
This PR fixes a `date humanize` bug and makes it use @LoicRiegel's newer
function `human_time_from_now()`.
### Before
```nushell
❯ (date now) + 3day
Wed, 11 Jun 2025 07:15:48 -0500 (in 3 days)
❯ (date now) + 3day | date humanize
in 2 days
```
### After
```nushell
❯ (date now) + 3day
Wed, 11 Jun 2025 07:23:10 -0500 (in 3 days)
❯ (date now) + 3day | date humanize
in 3 days
```
Closes#15916
# 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 sets the value to true by default only on Windows. This is not a
legacy code and is used by the Windows Terminal to detect the current
directory (explicitly enabling osc7 did not work). Here are the official
docs:
https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory
# User-Facing Changes
Windows users will by default have their terminals properly detect the
current working directory without extra configuration/troubleshooting.
<!--
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 current implementation of `polars pivot` calls an unsupported
version of pivot that throws a warning message in stdout (using
println!) stating that "unstable pivot not yet unsupported, using stable
pivot." This PR swaps out the call to `pivot` with a call to
`pivot_stable`, which is being done in the underlying polars anyways.
```nushell
# Current Implementation
> [[a b c]; [1 x 10] [1 y 10] [2 x 11] [2 y 11]] | polars into-df | polars pivot -i [a] -o [b] -v [c]
unstable pivot not yet supported, using stable pivot
╭───┬───┬────┬────╮
│ # │ a │ x │ y │
├───┼───┼────┼────┤
│ 0 │ 1 │ 10 │ 10 │
│ 1 │ 2 │ 11 │ 11 │
# Proposed Implementation (no println! statement)
> [[a b c]; [1 x 10] [1 y 10] [2 x 11] [2 y 11]] | polars into-df | polars pivot -i [a] -o [b] -v [c]
╭───┬───┬────┬────╮
│ # │ a │ x │ y │
├───┼───┼────┼────┤
│ 0 │ 1 │ 10 │ 10 │
│ 1 │ 2 │ 11 │ 11 │
╰───┴───┴────┴────╯
```
# 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
> ```
-->
Current suite of tests were sufficient
# 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!
-->
- basically reverts #15657
- still fixes#15584
- fixes#15784
- related https://github.com/tafia/calamine/pull/506
# 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 `zip` crate had some issues properly upgrading their repo and did
some yanking shenanigans. Since their yanking took so long `calamine`
tried to fix it but right now pinned to a yanked version of `zip`. This
breaks `cargo update`, `cargo add nu_command` and forces installs to use
`--locked`. For `calamine` exists [a
PR](https://github.com/tafia/calamine/pull/506) that would fix this but
right now that is not merged and we don't know when. Since we only
bumped `calamine` to fix#15584 and with the correctly yanked
`zip@2.5.0` we don't have that issue anymore. So I'm basically reverting
our `calamine` version. As soon as `calamine` updates with the new
version of `zip`, we can bump it again.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Should be 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
> ```
-->
- 🟢 `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 dependabot tries to bump `calamine` to `0.27.0`, we have to closed
that PR.
# Description
Updates `help where` to better explain row conditions, and provide more
examples. Also, the syntax shape is changed to `one_of(condition,
closure())>`. I don't think this should affect parsing at all because it
should still always be parsed as `SyntaxShape::RowCondition`, but it
should be more clear that you can use a row condition _or_ a closure
here, even if technically we consider closures to be row conditions
internally. In a similar vein, the help text makes this distinction
explicitly to make it more clear to users that closures are supported.
# User-Facing Changes
* Updated `where` help text
---------
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
Co-authored-by: Douglas <32344964+NotTheDr01ds@users.noreply.github.com>
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
- Updated the second @example for `find` to "Try to find an even
element" to match the closure logic.
- Updated the second @example for `find-index` to "Try to find the index
of an even element" for consistency.
I did a naive fix; which is probably all right.
But I want to spend some time to refactor a neighboring stuff.
And it's yet not to be released I guess;
I hope to add a few things beforehand.
I've just opened it so you can verify that it must be addressed.
close#15104, #14910, #15256
# Description
This PR fixes drive-letter glob expansion on Windows. It adds a bit of
pre-processing to play better with the wax crate.
This change is following suggestions from this thread on the wax repo:
https://github.com/olson-sean-k/wax/issues/34fixes#15707#7125
<!--
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#15884.
Adds `--disable-tag` flag to the `gstat` plugin that disables expensive
calculations. Instead `gstat` reports `no_tag`.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
There is no change in behaviour if the flag is not provided.
If the flag is provided, it will behave like there is no tags in the
repo, so no existing config will break.
**Title**: Better error handling for negative integer exponents in `**`
operator
---
### Bug Fix
This PR addresses an issue where attempting to raise an integer to a
negative power (e.g. `10 ** -1`) incorrectly triggered an
`OperatorOverflow` error. This behavior was misleading since the
overflow isn't actually the root problem — it's the unsupported
operation of raising integers to negative powers.
---
### Fix Summary
* Updated `Value::pow` to:
* Check for negative exponents when both operands are integers.
* Return a `ShellError::IncorrectValue` with a helpful message guiding
users to use floating point values instead.
#### Example:
```bash
> 10 ** -1
Error: nu:🐚:incorrect_value
× Incorrect value.
╝─[entry #2:1:4]
1 │ 10 ** -1
· ─┬┬
· │╰── encountered here
· ╰── Negative exponent for integer power is unsupported; use floats instead.
```
---
### Testing
Manual testing:
* `10 ** -1` → now returns a clear and appropriate `IncorrectValue`
error.
* `10.0 ** -1`, `10 ** -1.0`, etc. continue to work as expected.
---
### Related
Fixes#15860
---------
Co-authored-by: Kumar Ujjawal <kumar.ujjawal@greenpista.com>
# Description
This PR improves the installation process of Nushell's Windows Terminal
Profile by adding proper quoting when refilling the path to `nu.exe` and
`nu.ico`.
**Crossref:**
https://github.com/microsoft/terminal/issues/6082#issuecomment-1001226003
**Affected lines:**
222c307648/wix/main.wxs (L278-L282)
Currently, when any part of the installation path of `nu.exe` contains
spaces, the auto-generated profile would contain a truncated path due to
improper quoting. At best, this would cause failures when launching the
profile. At worst, this could lead to executable hijacks.
Assume this default-generated profile with the username "Mantle Bao":
```json
{
"profiles": [
{
"guid": "{47302f9c-1ac4-566c-aa3e-8cf29889d6ab}",
"name": "Nushell",
"commandline": "C:\\Users\\Mantle Bao\\AppData\\Local\\Programs\\nu\\bin\\nu.exe",
"icon": "C:\\Users\\Mantle Bao\\AppData\\Local\\Programs\\nu\\nu.ico",
"startingDirectory": "%USERPROFILE%"
}
]
}
```
And a file named "Mantle" exists under `C:\Users\`:
```nushell
> sudo nu -c `touch C:\Users\Mantle`
> ls `C:\Users\` | find "Mantle" | select name type
╭───┬─────────────────────────────────────────────────┬──────╮
│ # │ name │ type │
├───┼─────────────────────────────────────────────────┼──────┤
│ 0 │ C:\Users\Mantle │ file │
│ 1 │ C:\Users\Mantle Bao │ dir │
╰───┴─────────────────────────────────────────────────┴──────╯
>
```
Launching this profile produces this error in Windows Terminal
1.22.11141.0:
```plain-text
[error 2147942593 (0x800700c1) when launching `C:\Users\Mantle Bao\AppData\Local\Programs\nu\bin\nu.exe']
```
[Looking
up](https://learn.microsoft.com/en-us/windows/win32/debug/system-error-code-lookup-tool)
this error code would yield its name as `ERROR_BAD_EXE_FORMAT`, since
the Windows shell will try to execute `C:\\Users\\Mantle` but not the
actual `nu.exe`.
## Hijacking PoC
# User-Facing Changes
None. It should only affect the installation phase without any
user-facing changes.
# Tests + Formatting
This PR does not modify Rust or Nu code, and all its improvements belong
to the packaging system. Thus, no conventional tests or formatting
apply. But in case there exists preferred ways to test the packaging
process, please inform me of those, and I would make appropriate
changes.
# After Submitting
None. It should only affect the installation phase without any
post-submission edits.
# Description
Close: #15747
To support `reload` feature, we just need to save `caller_stack` before
adding overlay, then redirect_env back after the overlay is added.
# User-Facing Changes
NaN
# Tests + Formatting
Added 1 test
# After Submitting
NaN
# Description
Simple `parse` patterns let you quickly put together simple parsers, but
sometimes you aren't actually interested in some of the output (such as
variable whitespace). This PR lets you use `{_}` to discard part of the
input.
Example:
```nushell
"hello world" | parse "{foo} {_}"
# => ╭───┬───────╮
# => │ # │ foo │
# => ├───┼───────┤
# => │ 0 │ hello │
# => ╰───┴───────╯
```
here's a simple parser for the `apropops` using the `_` placeholder to
discard the variable whitespace, without needing to resort to a full
regex pattern:
```nushell
apropos linux | parse "{name} ({section}) {_}- {topic}"
# => ╭───┬───────────────────────────────────────┬─────────┬─────────────────────────────────────────────────────────────────────╮
# => │ # │ name │ section │ topic │
# => ├───┼───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
# => │ 0 │ PAM │ 8 │ Pluggable Authentication Modules for Linux │
# => │ 1 │ aarch64-linux-gnu-addr2line │ 1 │ convert addresses or symbol+offset into file names and line numbers │
# => │ 2 │ ... │ ... │ ... │
# => │ 3 │ xcb_selinux_set_window_create_context │ 3 │ (unknown subject) │
# => │ 4 │ xorriso-dd-target │ 1 │ Device evaluator and disk image copier for GNU/Linux │
# => ╰───┴───────────────────────────────────────┴─────────┴─────────────────────────────────────────────────────────────────────╯
```
# User-Facing Changes
* `parse` simple patterns can now discard input using `{_}`
# 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.
-->
When calling external commands, we convert our `$env` into a map where
each value is a string. If a value cannot be converted, it will be
skipped or when an `ENV_CONVERSION` is defined, will be converted via
that. This makes this conversion not that trivial. To ease debugging
this behavior or allowing to generate `.env` files from the current
environment did I add `debug env`.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
New command `debug env`.
# 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 did not add extra tests, as I just called the function we also call in
`start`, `exec` or `run-external`.
# 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 can use this to make my life easier implementing `colcon-nushell` 😉
# Description
This test has failed a number of times specifically on macOS. I'm not
exactly sure what the issue is, it seemed to work fine before. We should
probably actually fix it, but flaky CI is worse than missing this one
test on macOS
cc @cosineblast
# Description
Following #15843, I have tinkered more with it and realized that there
are plenty of features from
[hyperfine](https://github.com/sharkdp/hyperfine) that could be
implemented pretty easily.
- `--warmup` flag to do `n` runs without benchmarking first, useful to
fill disk cache
```nu
@example "use --warmup to fill the disk cache before benchmarking" { bench { fd } { jwalk . -k } -w 1 -n 10 }
```
- `--setup`, `--prepare`, `--cleanup`, `--conclude` flags to run code
before/after benchmarks
```nu
@example "use `--setup` to compile before benchmarking" { bench { ./target/release/foo } --setup { cargo build --release } }
@example "use `--prepare` to benchmark rust compilation speed" { bench { cargo build --release } --prepare { cargo clean } }
```
- `--ignore-errors` to ignore any errors in the benchmarked commands
- benchmarked commands are now `| ignore` so that externals don't fill
the screen
## Summary
This PR removes the required positional argument from the `which`
command, allowing it to accept input via the spread (`...`) operator.
This enables expressions like:
```nu
[notepad cmd] | which ...$in
```
Previously, this failed due to a missing required positional argument.
The Nushell runtime already handles empty input gracefully, so the
change aligns with existing behavior.
---
## Motivation
Making `which` compatible with splatted input improves composability and
aligns with user expectations in scriptable environments. It supports
patterns where the input may be constructed dynamically or piped in from
earlier commands.
---
## Changes
* Removed the `required` attribute from the positional argument in the
`which` command signature.
* No additional runtime logic required since empty input is handled
gracefully already.
---
## Examples
### Before
```nu
[notepad cmd] | which ...$in
# ❌ Error: Missing required positional argument
```
### After
```nu
[notepad cmd] | which ...$in
# ✅ Executes correctly
```
---
## Testing
* Ran `cargo test --all` and `cargo test -p nu-command`
* Manually tested using spread input with the `which` command
* Confirmed that empty and non-empty inputs behave correctly
---
## Related Issues
Closes
[[#15801](https://github.com/nushell/nushell/issues/15801)](https://github.com/nushell/nushell/issues/15801)
---------
Co-authored-by: Kumar Ujjawal <kumar.ujjawal@greenpista.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 seeks to port the polars command `replace`
(https://docs.pola.rs/api/python/stable/reference/expressions/api/polars.Expr.replace.html)
and `replace_strict`
(https://docs.pola.rs/api/python/stable/reference/expressions/api/polars.Expr.replace_strict.html).
See examples below.
Consequently, the current `polars replace` and `polars replace-all` have
been renamed to `polars str-replace` and `polars str-replace-all` to
bring their naming better in-line with `polars str-join` and related str
commands.
```nushell
Usage:
> polars replace {flags} <old> (new)
Flags:
-h, --help: Display the help message for this command
-s, --strict: Require that all values must be replaced or throw an error (ignored if `old` or `new` are expressions).
-d, --default <any>: Set values that were not replaced to this value. If no default is specified, (default), an error is raised if any values were not replaced. Accepts expression input. Non-expression inputs are parsed as literals.
-t, --return-dtype <string>: Data type of the resulting expression. If set to `null` (default), the data type is determined automatically based on the other inputs.
Parameters:
old <one_of(record, list<any>)>: Values to be replaced
new <list<any>>: Values to replace by (optional)
Input/output types:
╭───┬────────────┬────────────╮
│ # │ input │ output │
├───┼────────────┼────────────┤
│ 0 │ expression │ expression │
╰───┴────────────┴────────────╯
Examples:
Replace column with different values of same type
> [[a]; [1] [1] [2] [2]]
| polars into-df
| polars select (polars col a | polars replace [1 2] [10 20])
| polars collect
╭───┬────╮
│ # │ a │
├───┼────┤
│ 0 │ 10 │
│ 1 │ 10 │
│ 2 │ 20 │
│ 3 │ 20 │
╰───┴────╯
Replace column with different values of another type
> [[a]; [1] [1] [2] [2]]
| polars into-df
| polars select (polars col a | polars replace [1 2] [a b] --strict)
| polars collect
╭───┬───╮
│ # │ a │
├───┼───┤
│ 0 │ a │
│ 1 │ a │
│ 2 │ b │
│ 3 │ b │
╰───┴───╯
Replace column with different values based on expressions (cannot be used with strict)
> [[a]; [1] [1] [2] [2]]
| polars into-df
| polars select (polars col a | polars replace [(polars col a | polars max)] [(polars col a | polars max | $in + 5)])
| polars collect
╭───┬───╮
│ # │ a │
├───┼───┤
│ 0 │ 1 │
│ 1 │ 1 │
│ 2 │ 7 │
│ 3 │ 7 │
╰───┴───╯
Replace column with different values based on expressions with default
> [[a]; [1] [1] [2] [3]]
| polars into-df
| polars select (polars col a | polars replace [1] [10] --default (polars col a | polars max | $in * 100) --strict)
| polars collect
╭───┬─────╮
│ # │ a │
├───┼─────┤
│ 0 │ 10 │
│ 1 │ 10 │
│ 2 │ 300 │
│ 3 │ 300 │
╰───┴─────╯
Replace column with different values based on expressions with default
> [[a]; [1] [1] [2] [3]]
| polars into-df
| polars select (polars col a | polars replace [1] [10] --default (polars col a | polars max | $in * 100) --strict --return-dtype str)
| polars collect
╭───┬─────╮
│ # │ a │
├───┼─────┤
│ 0 │ 10 │
│ 1 │ 10 │
│ 2 │ 300 │
│ 3 │ 300 │
╰───┴─────╯
Replace column with different values using a record
> [[a]; [1] [1] [2] [2]]
| polars into-df
| polars select (polars col a | polars replace {1: a, 2: b} --strict --return-dtype str)
| polars collect
╭───┬───╮
│ # │ a │
├───┼───┤
│ 0 │ a │
│ 1 │ a │
│ 2 │ b │
│ 3 │ b │
╰───┴───╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
**BREAKING CHANGE**: `polars replace` and `polars replace-all` have been
renamed to `polars str-replace` and `polars str-replace-all`.
The new `polars replace` now replaces elements in a series/column rather
than patterns within strings.
# 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
> ```
-->
Example tests were 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.
-->
<!--
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 involves two changes: (1) adding `maintain-order` flag to
`polars group-by` for stable sorting when aggregating and (2) allow
expression inputs in `polars filter`. The first change was necessary to
reliably test the second change, and the two commits are therefore
combined in one PR. See example:
```nushell
# Filter a single column in a group-by context
> [[a b]; [foo 1] [foo 2] [foo 3] [bar 2] [bar 3] [bar 4]] | polars into-df
| polars group-by a --maintain-order
| polars agg {
lt: (polars col b | polars filter ((polars col b) < 2) | polars sum)
gte: (polars col b | polars filter ((polars col b) >= 3) | polars sum)
}
| polars collect
╭───┬─────┬────┬─────╮
│ # │ a │ lt │ gte │
├───┼─────┼────┼─────┤
│ 0 │ foo │ 1 │ 3 │
│ 1 │ bar │ 0 │ 7 │
╰───┴─────┴────┴─────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No 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
> ```
-->
An example test was added to `polars filter` demonstrating both the
stable group-by feature and the expression filtering feature.
# 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
- Use #15770 to
- improve `get --sensitive` deprecation warning
- add deprecation warning for `filter`
- refactor `filter` to use `where` as its implementation
- replace usages of `filter` with `where` in `std`
# User-Facing Changes
- `get --sensitive` will raise a warning only once, during parsing
whereas before it was raised during runtime for each usage.
- using `filter` will raise a deprecation warning, once
# Tests + Formatting
No existing test broke or required tweaking. Additional tests covering
this case was added.
- 🟢 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 and oversight. When we added `nul`, `null_byte`, and
`zero_byte` we forgot to make them non-printable for `char --list`.
That's what this PR fixes.
# 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.
-->
Hello!
This is my 1st contribution and an attempt at fixing #15417.
# Description
When parsing a brace expression, check if the shape is a block or match
block before attempting to parse it as a closure.
Results:
- `if true {|| print hi}` now produces a `nu::parser` error instead of
executing and outputting `hi`. The `nu::parser` error is the same one
produced by running `|| print hi` (`nu::parser::shell_oror`)
- `match true {|| print hi}` now fails with a `nu::parser` error instead
of passing parsing and failing with `nu::compile::invalid_keyword_call`
My understanding reading the code/docs is that the shape is a contextual
constraint that needs to be satisfied for parsing to succeed, in this
case the `if` placing a `Block` shape constraint on next tokens. So it
would need to be checked in priority (if not `Any`) to understand how
the next tokens should be parsed. Is that correct? Or is there a reason
I'm not aware of to ignore the shape and attempt to parse as closure
like it's currently the case when the parser sees `|` or `||` as next
tokens?
# User-Facing Changes
No change in behaviour, but this PR fixes parsing to fail on some
incorrect syntax which could be considered a breaking change.
# Tests + Formatting
- Added corresponding tests
- `toolkit check pr` passed
Fixes#15788
# Description
Fixes null handling. Thanks to @MMesch for reporting and taking a first
stab at fixing.
Co-authored-by: Jack Wright <jack.wright@nike.com>
# Description
Provides functionality similar to
https://docs.pola.rs/api/python/stable/reference/dataframe/api/polars.dataframe.group_by.GroupBy.first.html
by allowing polars first to be used with a group by
```
> ❯ : [[a b c d]; [1 0.5 true Apple] [2 0.5 true Orange] [2 4 true Apple] [3 10 false Apple] [4 13 false Banana] [5 14 true Banana]] | polars into-df -s {a: u8, b: f32, c: bool, d: str} | polars group-by d | polars first | polars collect
╭───┬────────┬───┬───────┬───────╮
│ # │ d │ a │ b │ c │
├───┼────────┼───┼───────┼───────┤
│ 0 │ Apple │ 1 │ 0.50 │ true │
│ 1 │ Banana │ 4 │ 13.00 │ false │
│ 2 │ Orange │ 2 │ 0.50 │ true │
╰───┴────────┴───┴───────┴───────╯
```
Additionally, I am setting the POLARS_ALLOW_EXTENSION to true to avoid
panicking with operations using the dtype object. The conversion will
fallback to object when the type cannot be determining, so this could be
a common case.
# User-Facing Changes
- `polars first` can now be used with `polars group-by`
---------
Co-authored-by: Jack Wright <jack.wright@nike.com>
# Description
Polars 0.48 upgrade
# User-Facing Changes
- (breaking change) Due to a change in behavior in polars, `polars
is-in` now only works as an expression.
---------
Co-authored-by: Jack Wright <jack.wright@nike.com>
# Description
Like [hyperfine](https://github.com/sharkdp/hyperfine), I have added the
option to the `bench` command to benchmark multiple commands and then
compare the results.
```
→ bench { ls -a | is-empty } { fd | is-empty }
# | code | mean | min | max | std | ratio
---+----------------------+------------------+-----------------+------------------+-------------+-------
0 | { ls -a | is-empty } | 3ms 816µs 562ns | 3ms 670µs 400ns | 4ms 334µs | 146µs 304ns | 1.00
1 | { fd | is-empty } | 33ms 325µs 304ns | 31ms 963µs | 36ms 328µs 500ns | 701µs 295ns | 8.73
→ bench -p { ls -a | is-empty } { fd | is-empty }
Benchmark 1: { ls -a | is-empty }
3ms 757µs 124ns +/- 103µs 165ns
Benchmark 2: { fd | is-empty }
33ms 403µs 680ns +/- 704µs 904ns
{ ls -a | is-empty } ran
8.89 times faster than { fd | is-empty }
```
When passing a single closure, it should behave the same except that
now, the `--verbose` flag controls whether the durations of every round
is printed, and the progress indicator is in it's own flag `--progress`.
# User-Facing Changes
There are user-facing changes, but I don't think anyone is using the
output of `bench` programmatically so it hopefully won't break anything.
---------
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
# Description
Adds the content type for `view span` output. Allows the display hook to
add syntax highlighting.
# User-Facing Changes
`view span` output will now have a content type set.
# Tests + Formatting
All pass, except for those that never pass on my machine.
# Description
Regex search and search with directly provided search terms used to
follow two different code paths. Now all possible search options get
turned into a regex, with optional additional search options, and
handled using a unified code path which mostly follows the logic of the
current term code path.
# User-Facing Changes
Regex search will now behave in the same way as non-regex search:
- split multiline strings into lists of lines, and filter out the lines
that don't match
- highlight matching string sections (unless --no-highlight flag is
used)
- search through the specified record columns if the --columns flag is
used
The behavior of non-regex search should be unaffected by this commit.
<!--
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 default `input` implementation with `reedline`. It
provides a fully backwards compatible implementation, by leveraging left
prompt provided through `input "my-prompt> "` provided by reedline.
The default indicator is hidden to be fully backwards compatible, the
multiline indicator is kept.
The legacy implementation will be used when the user passes options
truncating input such as `--bytes-until` or `--numchar` or
`--suppress-output` which I didn't find a straightforward implementation
through reedline.
# User-Facing Changes
No breaking change.
- Adds ability to enter multi-line input with reedline.
- Adds ability to pass a command history through the pipe `["command",
"history"] | input`- Adds ability to pass a history file through the
params `input --history-file path/to/history`
# 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: Darren Schroeder <343840+fdncred@users.noreply.github.com>
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR seeks to expand the `polars shift` command to take expression
inputs. See third example below:
```nushell
Examples:
Shifts the values by a given period
> [1 2 2 3 3] | polars into-df | polars shift 2 | polars drop-nulls
╭───┬───╮
│ # │ 0 │
├───┼───┤
│ 0 │ 1 │
│ 1 │ 2 │
│ 2 │ 2 │
╰───┴───╯
Shifts the values by a given period, fill absent values with 0
> [1 2 2 3 3] | polars into-lazy | polars shift 2 --fill 0 | polars collect
╭───┬───╮
│ # │ 0 │
├───┼───┤
│ 0 │ 0 │
│ 1 │ 0 │
│ 2 │ 1 │
│ 3 │ 2 │
│ 4 │ 2 │
╰───┴───╯
Shift values of a column, fill absent values with 0
> [[a]; [1] [2] [2] [3] [3]]
| polars into-lazy
| polars with-column {b: (polars col a | polars shift 2 --fill 0)}
| polars collect
╭───┬───┬───╮
│ # │ a │ b │
├───┼───┼───┤
│ 0 │ 1 │ 0 │
│ 1 │ 2 │ 0 │
│ 2 │ 2 │ 1 │
│ 3 │ 3 │ 2 │
│ 4 │ 3 │ 2 │
╰───┴───┴───╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No 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
> ```
-->
An example test was added to `polars shift`
# 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 enhances the MSI release workflow by allowing the MSI package
version to be specified either through an environment variable or a
workflow input. This improvement provides greater flexibility when
building MSI packages for tags that do **not** match the latest package
version in `Cargo.toml`.
Fix possible **403** error while updating `SHA256SUMS` file in the
nushell/nightly repo
# User-Facing Changes
None
# Tests + Formatting
A example running record:
https://github.com/nushell/nightly/actions/runs/15265879087/job/42931344366#step:5:11
# Description
Fixes#15734. With case-insensitive matching, when completing a
file/folder, there can be multiple exact matches. For example, if you
have three folders `aa/`, `AA/`, and `aaa/`, `aa/<TAB>` should match all
of them. But, as reported in #15734, when using prefix matching, only
`AA/` will be shown. This is because when there's an exact match in
prefix match mode, we only show the first exact match.
There are two options for fixing this:
- Show all matched suggestions (`aa/`, `AA/`, and `aaa/`)
- I chose this option
- Show only the suggestions that matched exactly (`aa/` and `AA/`) but
not others (`aaa/`)
- This felt unintuitive
# User-Facing Changes
As mentioned above, when:
- you have multiple folders with the same name but in different cases
- and you're using prefix matching
- and you're using case-insensitive matching
- and you type in the name of one of these folders exactly
then you'll be suggested every folder matching the typed text, rather
than just exact matches
# Tests + Formatting
I added a test that doesn't run on Windows or MacOS (to avoid
case-insensitive filesystems). While adding this test, I felt like using
`Playground` rather than adding files to `tests/fixtures`. To make this
easier, I refactored the `new_*_engine()` helpers in
`completion_helpers.rs` a bit. There was quite a bit of code duplication
there.
# 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 adds a number of math functions under a single `polars math`
command that apply to one or more column expressions.
Note, `polars math` currently resides in the new module
dataframe/command/command/computation/math.rs. I'm open to alternative
organization and naming suggestions.
```nushell
Collection of math functions to be applied on one or more column expressions
This is an incomplete implementation of the available functions listed here: https://docs.pola.rs/api/python/stable/reference/expressions/computation.html.
The following functions are currently available:
- abs
- cos
- dot <expression>
- exp
- log <base; default e>
- log1p
- sign
- sin
- sqrt
Usage:
> polars math <type> ...(args)
Flags:
-h, --help: Display the help message for this command
Parameters:
type <string>: Function name. See extra description for full list of accepted values
...args <any>: Extra arguments required by some functions
Input/output types:
╭───┬────────────┬────────────╮
│ # │ input │ output │
├───┼────────────┼────────────┤
│ 0 │ expression │ expression │
╰───┴────────────┴────────────╯
Examples:
Apply function to column expression
> [[a]; [0] [-1] [2] [-3] [4]]
| polars into-df
| polars select [
(polars col a | polars math abs | polars as a_abs)
(polars col a | polars math sign | polars as a_sign)
(polars col a | polars math exp | polars as a_exp)]
| polars collect
╭───┬───────┬────────┬────────╮
│ # │ a_abs │ a_sign │ a_exp │
├───┼───────┼────────┼────────┤
│ 0 │ 0 │ 0 │ 1.000 │
│ 1 │ 1 │ -1 │ 0.368 │
│ 2 │ 2 │ 1 │ 7.389 │
│ 3 │ 3 │ -1 │ 0.050 │
│ 4 │ 4 │ 1 │ 54.598 │
╰───┴───────┴────────┴────────╯
Specify arguments for select functions. See description for more information.
> [[a]; [0] [1] [2] [4] [8] [16]]
| polars into-df
| polars select [
(polars col a | polars math log 2 | polars as a_base2)]
| polars collect
╭───┬─────────╮
│ # │ a_base2 │
├───┼─────────┤
│ 0 │ -inf │
│ 1 │ 0.000 │
│ 2 │ 1.000 │
│ 3 │ 2.000 │
│ 4 │ 3.000 │
│ 5 │ 4.000 │
╰───┴─────────╯
Specify arguments for select functions. See description for more information.
> [[a b]; [0 0] [1 1] [2 2] [3 3] [4 4] [5 5]]
| polars into-df
| polars select [
(polars col a | polars math dot (polars col b) | polars as ab)]
| polars collect
╭───┬────────╮
│ # │ ab │
├───┼────────┤
│ 0 │ 55.000 │
╰───┴────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No 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
> ```
-->
Example tests were added to `polars math`.
# 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.
-->
Merged PR #15553 added the ability to provide expressions in the form of
records. This PR conforms the `NuExpression::can_downcast` logic to
account for the newly allowed records argument type. As such, commands
that rely on `can_downcast` in their implementation (e.g., `polars
with-column`) will no longer err when provided with a record. See
example below:
```nushell
# Current error
> [[a b]; [1 2] [3 4]]
| polars into-df <-- only works if cast as lazyframe
| polars with-column {
c: ((polars col a) * 2)
d: ((polars col a) * 3)
}
Error: nu:🐚:cant_convert
× Can't convert to NuDataFrame, NuLazyFrame, NuExpression, NuLazyGroupBy, NuWhen,
│ NuDataType, NuSchema.
╭─[entry #24:3:26]
2 │ | polars into-df
3 │ ╭─▶ | polars with-column {
4 │ │ c: ((polars col a) * 2)
5 │ │ d: ((polars col a) * 3)
6 │ ├─▶ }
· ╰──── can't convert record<c: NuExpression, d: NuExpression> to NuDataFrame, NuLazyFrame, NuExpression, NuLazyGroupBy, NuWhen, NuDataType, NuSchema
╰────
# Fixed
> [[a b]; [1 2] [3 4]]
| polars into-df
| polars with-column {
c: ((polars col a) * 2)
d: ((polars col a) * 3)
} | polars collect
╭───┬───┬───┬───┬───╮
│ # │ a │ b │ c │ d │
├───┼───┼───┼───┼───┤
│ 0 │ 1 │ 2 │ 2 │ 3 │
│ 1 │ 3 │ 4 │ 6 │ 9 │
╰───┴───┴───┴───┴───╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No 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
> ```
-->
An example test was added to `polars with-column`.
# 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 pull request addresses an issue#15813 where passing a infinite
value in the random float 1.. command that causes a panic in the shell.
The root cause of this problem lies within the rng library, which is
responsible for generating random numbers.
Before
# User-Facing Changes
Users where seeing panic error when passed unbounded end into range.
# Tests + Formatting
added `generate_inf`
# After Submitting
No error should be there after
Edit history
1. Updated `After Submitting` section
---------
Co-authored-by: Ritik Ranjan <e02948@ritik.ranjan@hsc.com>
- related #10698
# Description
In my endeavor to make the `ShellError` less crowded I moved the job
related errors into `ShellError::Job` with a `JobError` enum. Mostly I
just moved the codes, errors and labels over to the new enum.
https://github.com/nushell/nushell/issues/10957
Hello, this PR proposes a solution for some requested features mentioned
in https://github.com/nushell/nushell/issues/10957. I personally think
these are very simple changes that bring significant quality of life
improvements.
It gives the possibility to do `http get google.com` instead of `http
get http://google.com` and `http get :8080` instead of `http get
http://localhost:8080`.
I did not address the other part of the issue (data management) as those
are more controversial.
<!--
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 comments of release-pkg.nu for building of MSI package
Fixes#15571
# Description
Writing to a source `.parquet` (`polars open some_file.parquet | polars
save some_file.parquet`) file made the plugin panic, added a guard to
check the data_source path as per [this
comment](https://github.com/nushell/nushell/issues/15571#issuecomment-2812707161)
Example output now:
<img width="850" alt="Screenshot 2025-04-18 at 21 10 30"
src="https://github.com/user-attachments/assets/40a73cc7-6635-43dc-a423-19c7a0c8f59c"
/>
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
- Add 1 test
- clippy OK
- cargo fmt OK
# After Submitting
No action required
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
closes#14041
# 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 switches our default TLS backend from `native-tls` to `rustls`.
Cross-compiles, `musl`, and other targets build smoother because we drop
the OpenSSL requirement.
`native-tls` is still available as an opt-in on `nu-command` via the
`native-tls` feature.
WASM + `network` still fails for unrelated crates, but the OpenSSL
roadblock is gone.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No changes to the Nushell API.
If you embed Nushell you now need to pick a
[`rustls::crypto::CryptoProvider`](https://docs.rs/rustls/0.23.27/rustls/crypto/struct.CryptoProvider.html)
at startup:
```rust
use nu_command::tls::CRYPTO_PROVIDER;
// common case
CRYPTO_PROVIDER.default();
// or supply your own
CRYPTO_PROVIDER.set(|| Ok(my_provider()));
```
# 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
Fixes: https://github.com/nushell/nushell/issues/15749
When sourcing a file, the ir block might be empty because it has been
used before, this pr is going to make sure that the ir block is
compiled.
# User-Facing Changes
```
touch aaa.nu
use aaa.nu
source aaa.nu
```
Will no longer raise an error.
# Tests + Formatting
Added 1 test
# After Submitting
NaN
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# 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.
-->
Bump dev version to 0.104.2
<!--
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.
-->
Try to use nushell's fork for winget-pkgs publishing
# Description
`pub` has been overused in many parts of `nu-protocol`. This exposes
implementation details in ways that things could break should we involve
the internals. Also each public member can slow down the decisions to
improve a certain implementation. Furthermore dead code can't be
detected if things are marked as `pub`. Thus we need to judiciously
remove more accidentally `pub` markings and eliminate the dead code if
we come across it.
This PR tackles `EngineState` and `StateWorkingSet` as important
components of the engine and `nu-protocol`. Prompted by a large number
of confusingly named methods surrounding overlays and scope management.
- **Hide overlay predecl logic**
- **Remove dead overlay code**
- **Remove unused helper**
- **Remove dead overlay code from `EngineState`**
- **Hide update_plugin_file impl detail**
- **Hide another overlay internal detail`**
# API User-Facing Changes
Removal of several formerly public members that potentially give
intrusive access to the engine. We will button up some of our public
API, feel free to explicitly complain so we can figure out what access
should be granted. We want to evolve to stable APIs as much as possible
which means hiding more implementation details and committing to a
select few well defined and documented interfaces
<!--
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.
-->
Publishing Nushell to winget has always been a challenge for us, and to
this day, many issues remain unresolved—and some seem almost impossible
to fix. The road to solving these problems may be winding and long, but
it's time for us to set out on this journey.
This PR try to fix the Windows arm64 release binaries and some `winget`
related issues:
- [x] Fixes https://github.com/nushell/nushell/issues/14815: build
Windows arm64 binaries by Windows arm64 runner
- [x] Upgrade WiX Toolset to latest 6.0 version: WiX 3 we used currently
doesn't support arm64 arch and [WiX v4 Security Fixes End Date is
2025/02/05](https://docs.firegiant.com/wix/)
- [x] Update the **nightly** workflow to make it work for all future
releases
- [x] Update the **release** workflow to make it work for all future
releases
- [x] Fixes https://github.com/nushell/nushell/issues/15698
- [x] Fixes https://github.com/nushell/nushell/issues/13719 so that
Nushell should be possible to be installed via winget with both user and
machine scope
- [x] Fixes https://github.com/nushell/nushell/issues/5927
- [x] Try to fix https://github.com/nushell/nushell/issues/14786
- [x] Fixes https://github.com/nushell/nushell/issues/9537
## Related but not planed issues:
- Related https://github.com/nushell/nushell/issues/13017
- Related https://github.com/nushell/nushell/issues/8053
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
- Nushell should be possible to be installed via winget with both user
and machine scope and The default should be user scope
- User scope install by winget: `winget install Nushell.Nushell`
- User scope install by msiexec: `msiexec /i
nu-0.104.1-x86_64-pc-windows-msvc.msi /quiet /qn`
- Machine scope install by winget: `winget install Nushell.Nushell
--override 'ALLUSERS=1'`
- Machine scope install by msiexec: `msiexec /i
nu-0.104.1-x86_64-pc-windows-msvc.msi ALLUSERS=1`
- Note that `--scope` flag for `winget install` does not work use
`--override` instead
- Default user scope install dir:
`$'($nu.home-path)\AppData\Local\Programs\nu\'`
- Default machine scope install dir: `C:\Program Files\nu\`
- When a standard user runs the installer and selects "Install for
everyone" (per-machine installation), Windows will automatically trigger
a UAC prompt, the user can enter admin credentials and the installation
will proceed with elevated privileges
- [hustcer/setup-nu](https://github.com/hustcer/setup-nu) should work
for `windows-11-arm` runners
# 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 latest MSI builds are available here:
https://github.com/nushell/nightly/releases/tag/v0.104.1
Actually all the nightly releases were built with latest changes
included: https://github.com/nushell/nightly/releases
`winget` and `msiexec` install tests goes here:
https://github.com/nushell/integrations/pull/49https://github.com/nushell/integrations/actions/runs/14974621061https://github.com/nushell/integrations/actions/runs/14974621054
### Test winget install locally:
- git clone git@github.com:nushell/integrations.git
- User scope install: `winget install -m
manifests\n\Nushell\Nushell\0.104.1\`
- Run: `use tests\common.nu *; check-user-install`
- Machine scope install: `winget install -m
manifests\n\Nushell\Nushell\0.104.1\ --override 'ALLUSERS=1'`
- Run: `use tests\common.nu *; check-local-machine-install`
# 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.
-->
@fdncred I suggest releasing a patch version after merging this PR (only
the changes of this PR will be included) to ensure that the winget
release process works properly. This way, we can be more confident when
releasing version 0.105.0.
References:
-
https://learn.microsoft.com/en-us/windows/win32/msi/single-package-authoring
-
https://learn.microsoft.com/en-us/windows/package-manager/winget/source#add
-
https://github.com/microsoft/winget-pkgs/blob/master/doc/tools/SandboxTest.md
- https://docs.firegiant.com/quick-start/
-
https://docs.firegiant.com/wix3/tutorial/getting-started/putting-it-to-use/#_top
-
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec#set-public-properties
Related:
- #15683
- #14551
- #849
- #12701
- #11527
# Description
Currently various commands have differing behavior regarding cell-paths
```nushell
{a: 1, A: 2} | get a A
# => ╭───┬───╮
# => │ 0 │ 2 │
# => │ 1 │ 2 │
# => ╰───┴───╯
{a: 1, A: 2} | select a A
# => ╭───┬───╮
# => │ a │ 1 │
# => │ A │ 2 │
# => ╰───┴───╯
{A: 1} | update a 2
# => Error: nu:🐚:column_not_found
# =>
# => × Cannot find column 'a'
# => ╭─[entry #62:1:1]
# => 1 │ {A: 1} | update a 2
# => · ───┬── ┬
# => · │ ╰── cannot find column 'a'
# => · ╰── value originates here
# => ╰────
```
Proposal: making cell-path access case-sensitive by default and adding
new syntax for case-insensitive parts, similar to optional (?) parts.
```nushell
{FOO: BAR}.foo
# => Error: nu:🐚:name_not_found
# =>
# => × Name not found
# => ╭─[entry #60:1:21]
# => 1 │ {FOO: BAR}.foo
# => · ─┬─
# => · ╰── did you mean 'FOO'?
# => ╰────
{FOO: BAR}.foo!
# => BAR
```
This would solve the problem of case sensitivity for all commands
without causing an explosion of flags _and_ make it more granular
Assigning to a field using a case-insensitive path is case-preserving.
```nushell
mut val = {FOO: "I'm FOO"}; $val
# => ╭─────┬─────────╮
# => │ FOO │ I'm FOO │
# => ╰─────┴─────────╯
$val.foo! = "I'm still FOO"; $val
# => ╭─────┬───────────────╮
# => │ FOO │ I'm still FOO │
# => ╰─────┴───────────────╯
```
For `update`, case-insensitive is case-preserving.
```nushell
{FOO: 1} | update foo! { $in + 1 }
# => ╭─────┬───╮
# => │ FOO │ 2 │
# => ╰─────┴───╯
```
`insert` can insert values into nested values so accessing into existing
columns is case-insensitive, but creating new columns uses the cell-path
as it is.
So `insert foo! ...` and `insert FOO! ...` would work exactly as they do
without `!`
```nushell
{FOO: {quox: 0}}
# => ╭─────┬──────────────╮
# => │ │ ╭──────┬───╮ │
# => │ FOO │ │ quox │ 0 │ │
# => │ │ ╰──────┴───╯ │
# => ╰─────┴──────────────╯
{FOO: {quox: 0}} | insert foo.bar 1
# => ╭─────┬──────────────╮
# => │ │ ╭──────┬───╮ │
# => │ FOO │ │ quox │ 0 │ │
# => │ │ ╰──────┴───╯ │
# => │ │ ╭─────┬───╮ │
# => │ foo │ │ bar │ 1 │ │
# => │ │ ╰─────┴───╯ │
# => ╰─────┴──────────────╯
{FOO: {quox: 0}} | insert foo!.bar 1
# => ╭─────┬──────────────╮
# => │ │ ╭──────┬───╮ │
# => │ FOO │ │ quox │ 0 │ │
# => │ │ │ bar │ 1 │ │
# => │ │ ╰──────┴───╯ │
# => ╰─────┴──────────────╯
```
`upsert` is tricky, depending on the input, the data might end up with
different column names in rows. We can either forbid case-insensitive
cell-paths for `upsert` or trust the user to keep their data in a
sensible shape.
This would be a breaking change as it would make existing cell-path
accesses case-sensitive, however the case-sensitivity is already
inconsistent and any attempt at making it consistent would be a breaking
change.
> What about `$env`?
1. Initially special case it so it keeps its current behavior.
2. Accessing environment variables with non-matching paths gives a
deprecation warning urging users to either use exact casing or use the
new explicit case-sensitivity syntax
3. Eventuall remove `$env`'s special case, making `$env` accesses
case-sensitive by default as well.
> `$env.ENV_CONVERSIONS`?
In addition to `from_string` and `to_string` add an optional field to
opt into case insensitive/preserving behavior.
# User-Facing Changes
- `get`, `where` and other previously case-insensitive commands are now
case-sensitive by default.
- `get`'s `--sensitive` flag removed, similar to `--ignore-errors` there
is now an `--ignore-case` flag that treats all parts of the cell-path as
case-insensitive.
- Users can explicitly choose the case case-sensitivity of cell-path
accesses or commands.
# Tests + Formatting
Existing tests required minimal modification. ***However, new tests are
not yet added***.
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
- Update the website to include the new syntax
- Update [tree-sitter-nu](https://github.com/nushell/tree-sitter-nu)
---------
Co-authored-by: Bahex <17417311+Bahex@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.
-->
`polars unique` currently only operates on entire dataframes. This PR
seeks to expand this command to handle expressions as well. See
examples:
```nushell
Returns unique values in a subset of lazyframe columns
> [[a]; [2] [1] [2]]
| polars into-lazy
| polars select (polars col a | polars unique)
| polars collect
╭───┬───╮
│ # │ a │
├───┼───┤
│ 0 │ 1 │
│ 1 │ 2 │
╰───┴───╯
Returns unique values in a subset of lazyframe columns
> [[a]; [2] [1] [2]]
| polars into-lazy
| polars select (polars col a | polars unique --maintain-order)
| polars collect
╭───┬───╮
│ # │ a │
├───┼───┤
│ 0 │ 2 │
│ 1 │ 1 │
╰───┴───╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have the added option to use `polars unique`
in an expressions context.
# 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
> ```
-->
Example tests have been added to `polars unique`
# 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#14469
# Description
- ~~Implement the ``--unit`` conversion in "into int" command~~
- New ``ShellError::InvalidUnit`` unit if users enter wrong units
- Made ``ShellError::CantConvertToDuration`` more generic: became
``CantConvertToUnit``
- Tried to improve the way we parse units and get the supported units.
It's not complete, though, I will continue this refactoring in another
PR. But I already did some small refactorings in the "format duration"
and "format filesize" commands
- Add tests for "format filesize" and "format duration"
# User-Facing Changes
```nu
~> 1MB | format filesize sec
Error: nu:🐚:invalid_unit
× Invalid unit
╭─[entry #7:1:23]
1 │ 1MB | format filesize sec
· ─┬─
· ╰── encountered here
╰────
help: Supported units are: B, kB, MB, GB, TB, PB, EB, KiB, MiB, GiB, TiB, PiB, EiB
```
# Description
In preparation for https://github.com/nushell/reedline/pull/798, which
adds a new field to `Suggestion`, this PR makes sure that `Suggestion`s
are created using `..Default::default()` inside
`attribute_completions.rs`.
# User-Facing Changes
None
# Tests + Formatting
None
# After Submitting
# Description
This PR adds lazy closure evaluation to the `default` command (closes
#14160).
- For non-closure values and without providing a column name, `default`
acts the same as before
- The user can now provide multiple column names to populate if empty
- If the user provides a column name, the input must be a record or
list, otherwise an error is created.
- The user can now provide a closure as a default value
- This closure is run without any arguments or input
- The closure is never evaluated if the value isn't needed
- Even when column names are supplied, the closure is only run once (and
cached to prevent re-calling it)
For example:
```nushell
> default { 1 + 2 } # => 3
> null | default 3 a # => previously `null`, now errors
> 1 | default { sleep 5sec; 3 } # => `1`, without waiting 5 seconds
> let optional_var = null; $optional_var | default { input 'Enter value: ' } # => Returns user input
> 5 | default { input 'Enter value: ' } # => `5`, without prompting user
> ls | default { sleep 5sec; 'N/A' } name # => No-op since `name` column is never empty
> ls | default { sleep 5sec; 'N/A' } foo bar # => creates columns `foo` and `bar`; only takes 5 seconds since closure result is cached
# Old behavior is the same
> [] | default 'foo' # => []
> [] | default --empty 'foo' # => 'foo'
> default 5 # => 5
```
# User-Facing Changes
- Users can add default values to multiple columns now.
- Users can now use closures as the default value passed to `default`.
- To return a closure, the user must wrap the closure they want to
return inside another closure, which will be run (`default { $my_closure
}`).
# Tests + Formatting
All tests pass.
# After Submitting
---------
Co-authored-by: 132ikl <132@ikl.sh>
# Description
This PR fixes a bug where powershell scripts were only allowed to be
executed if they were in the directory that you executed them from. This
fix allows the scripts to be anywhere in the path.
closes#15759
# 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!
-->
- fixes#14896
- related to #15163
# 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 presence of ansi color codes in empty tables, when
`$env.config.table.show_empty = true` and `$env.config.use_ansi_coloring
= false`
# User-Facing Changes
Empty tables respect `$env.config.use_ansi_coloring`
# 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 test for this case.
# After Submitting
- fixes#15731
# Description
Existing bare word string interpolation only works if the string doesn't
start with a subxpression.
```nushell
echo fork(2)
# => fork2
echo (2)fork
# => Error: nu::parser::unclosed_delimiter
# =>
# => × Unclosed delimiter.
# => ╭─[entry #25:1:13]
# => 1 │ echo (2)fork
# => ╰────
```
This PR lifts that restriction.
```nushell
echo fork(2)
# => fork2
echo (2)fork
# => 2fork
```
This was first brought to my attention on discord with the following
command failing to parse.
```nushell
docker run -u (id -u):(id -g)
```
It now works.
# User-Facing Changes
# Tests + Formatting
No existing test broke or required tweaking. Additional tests covering
this case was added.
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
Fixes#15128. Allows `path join` to use ByteStream pipeline data to join
on if it's coercible to string. Binary ByteStream input still results in
an error. Tested with `^$nu.current-exe -c '$nu.config-path' | path join
foo` and `^tar.exe -c assets/nu_logo.ico | path join foo`
# User-Facing Changes
If an external command returns a path, users would previously need to
use `^show-path-cmd | collect | path join 'foo'`, now they can drop the
intermediate `collect`.
Even with some experience in Nushell I did not find information about
the match syntax for alternative value matches. The `match` command help
does not mention it at all. I suggest we add an example.
Previously, the examples only had "advanced" matching operations. It
seems appropriate to start with the simplest one: Matching by value.
Add both of these examples.
# User-Facing Changes
`help match` and the [command reference
docs](https://www.nushell.sh/commands/docs/match.html) now have examples
for
* simple value matching
* alternative value matching
Bumps [miette](https://github.com/zkat/miette) from 7.5.0 to 7.6.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/zkat/miette/blob/main/CHANGELOG.md">miette's
changelog</a>.</em></p>
<blockquote>
<h2>7.6.0 (2025-04-27)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>graphical:</strong> prevent leading newline when no
link/code (<a
href="https://redirect.github.com/zkat/miette/issues/418">#418</a>) (<a
href="1e1938a099">1e1938a0</a>)</li>
<li><strong>clippy:</strong> elide lifetimes (<a
href="https://redirect.github.com/zkat/miette/issues/423">#423</a>) (<a
href="9ba6fad769">9ba6fad7</a>)</li>
<li><strong>highlight:</strong> increase syntax highlighter config
priority (<a
href="https://redirect.github.com/zkat/miette/issues/424">#424</a>) (<a
href="58d9f12411">58d9f124</a>)</li>
<li><strong>deps:</strong> miette can now be used without syn (<a
href="https://redirect.github.com/zkat/miette/issues/436">#436</a>) (<a
href="521ef91f77">521ef91f</a>)</li>
</ul>
<h3>Features</h3>
<ul>
<li><strong>graphical:</strong> support rendering related diagnostics as
nested (<a
href="https://redirect.github.com/zkat/miette/issues/417">#417</a>) (<a
href="771a07519f">771a0751</a>)</li>
<li><strong>labels:</strong> add support for disabling the primary label
line/col information (<a
href="https://redirect.github.com/zkat/miette/issues/419">#419</a>) (<a
href="f2ef693d1c">f2ef693d</a>)</li>
<li><strong>deps:</strong> update <code>thiserror</code> from 1.0.56 to
2.0.11 (<a
href="https://redirect.github.com/zkat/miette/issues/426">#426</a>) (<a
href="59c81617de">59c81617</a>)</li>
</ul>
<p><!-- raw HTML omitted --><!-- raw HTML omitted --></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/zkat/miette/commits/miette-derive-v7.6.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>
Fixes#15716
# Description
Returns None early if the input iterator is depleted.
# User-Facing Changes
Should be none
# Tests + Formatting
+1
# After Submitting
A small optimization;
Must be measurable on large tables.
In case of `scope commands` for me seems like a bit faster in debug
(~100ms).
But I've had like a few runs.
If someone is interested to check if it's any faster would be nice to
see it :)
cc: @fdncred
# Description
Fixes#9942
This adds a new `--minified` flag to `to nuon` which removes all
possible white space. I added an example test to demonstrate the
functionality.
# User-Facing Changes
New flag becomes available to the user.
ref #15653
Thanks for reproducible.
So @Bahex indeed padding was not properly handled.
I am not sure whether there's more issues related to your examples
@fdncred but I seems like don't get them.
Also added a test for future regressions (well to be honest didn't
tested that it's failing on main but at least at may catch something)
PS: Also got some panic related to #15138 (which PR fixed) :(
There's nothing on my end stopping me releasing a WASM issue fix; I just
sort of always worrying with releasing a `patch` (`0.0.x`)......and
there's 1 quite big thing I wanna do before a minor release.......
# Description
See [this
discussion](https://discord.com/channels/601130461678272522/1353434388938883143/1360664695962341647)
on discord
Goal: as the AST evaluator isn't supported anymore, I removed the body
of the "run" methods of some commands that were actually never run
because the IR is used instead.
Note: the code inside the "run_const" methods seems to be run, so I left
it.
Cc @132ikl
# User-Facing Changes
None
# Tests + Formatting
I didn't do any manual testing, I just ran the tests
# After Submitting
Nothing required I think
Bumps [quickcheck_macros](https://github.com/BurntSushi/quickcheck) from
1.0.0 to 1.1.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="d58e3cffb7"><code>d58e3cf</code></a>
quickcheck_macros-1.1.0</li>
<li><a
href="03ab585865"><code>03ab585</code></a>
Fix README examples</li>
<li><a
href="826f10baa1"><code>826f10b</code></a>
Add shrinking support for arrays (<a
href="https://redirect.github.com/BurntSushi/quickcheck/issues/330">#330</a>)</li>
<li><a
href="87b46b90ec"><code>87b46b9</code></a>
Update some links (<a
href="https://redirect.github.com/BurntSushi/quickcheck/issues/332">#332</a>)</li>
<li><a
href="a0216c932f"><code>a0216c9</code></a>
Revert <code>Gen</code> renaming, rename <code>gen</code> method</li>
<li><a
href="2c2cd21935"><code>2c2cd21</code></a>
Update to rand 0.9</li>
<li><a
href="9ddbbd6b68"><code>9ddbbd6</code></a>
deps: update to syn 2.0 (<a
href="https://redirect.github.com/BurntSushi/quickcheck/issues/317">#317</a>)</li>
<li><a
href="238f340a36"><code>238f340</code></a>
Bump MSRV to 1.71</li>
<li><a
href="32d7bc4edf"><code>32d7bc4</code></a>
Upgrade to 2021 edition</li>
<li><a
href="44b81bebcf"><code>44b81be</code></a>
deps: update to env_logger 0.11 (<a
href="https://redirect.github.com/BurntSushi/quickcheck/issues/327">#327</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/BurntSushi/quickcheck/compare/quickcheck_macros-1.0.0...quickcheck_macros-1.1.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Description
Move clear jobs to _after_ traversing them, in order to kill them.
# User-Facing Changes
None
# Tests + Formatting
It looks like it's only used once, in crates/nu-engine/src/exit.rs
Fixes#15675
I've added relevant test cases to ensure coverage of the identified bug.
The issue originated from my crate and pertains to the bracoxide
dependency—a bug I’ve internally referred to as IgnorantNumbers. I’ve
submitted a fix and updated the bracoxide dependency 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.
-->
# 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!
-->
closes#15381
# 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 new table mode called `single`, it looks like the `heavy` mode,
but the key difference is that it uses thinner lines. I decided on the
name `single` because it's one of the border styles Neovim uses, and
they look practically the same.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
New config option:
```nushell
$env.config.table.mode = 'single'
```
# 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 new tests in `crates/nu-table/tests/style.rs` to cover the single
table mode.
# 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.
-->
A bug introduced by #14920
When `use module.nu` is called, all exported constants defined in it are
added to the scope.
# Description
On the branch of empty arguments, the constant var_id vector should be
empty, only constant_values (for `$module.foo` access) are injected.
# User-Facing Changes
# Tests + Formatting
~todo!~
adjusted
# 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.
-->
I was interested in how nu-shell handles glibc, especially older
versions of it. I figured out from the docs that ubuntu 20.04 is
utilized. However, in reality, github has deprecated ubuntu 20.04, and
the code for ci.yaml in github workflow clearly states that it is 22.04.
This is just a minor doc update to clarify forgotten information
<!--
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 port over the `*_horizontal` commands in polars
rust/python (e.g.,
https://docs.pola.rs/api/python/stable/reference/expressions/api/polars.sum_horizontal.html),
which aggregate across multiple columns (as opposed to rows). See below
for several examples.
```nushell
# Horizontal sum across two columns (ignore nulls by default)
> [[a b]; [1 2] [2 3] [3 4] [4 5] [5 null]]
| polars into-df
| polars select (polars horizontal sum a b)
| polars collect
╭───┬─────╮
│ # │ sum │
├───┼─────┤
│ 0 │ 3 │
│ 1 │ 5 │
│ 2 │ 7 │
│ 3 │ 9 │
│ 4 │ 5 │
╰───┴─────╯
# Horizontal sum across two columns while accounting for nulls
> [[a b]; [1 2] [2 3] [3 4] [4 5] [5 null]]
| polars into-df
| polars select (polars horizontal sum a b --nulls)
| polars collect
╭───┬─────╮
│ # │ sum │
├───┼─────┤
│ 0 │ 3 │
│ 1 │ 5 │
│ 2 │ 7 │
│ 3 │ 9 │
│ 4 │ │
╰───┴─────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have access to a new command, `polars
horizontal`.
# 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
> ```
-->
Example tests were added to `polars horizontal`.
# 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
While working on something else, I noticed that
`Value::follow_cell_path` receives `self`.
While it would be ideal for the signature to be `(&'a self, cell_path)
-> &'a Value`, that's not possible because:
1. Selecting a row from a list and field from a record can be done with
a reference but selecting a column from a table requires creating a new
list.
2. `Value::Custom` returns new `Value`s when indexed.
So the signature becomes `(&'a self, cell_path) -> Cow<'a, Value>`.
Another complication that arises is, once a new `Value` is created, and
it is further indexed, the `current` variable
1. can't be `&'a Value`, as the lifetime requirement means it can't
refer to local variables
2. _shouldn't_ be `Cow<'a, Value>`, as once it becomes an owned value,
it can't be borrowed ever again, as `current` is derived from its
previous value in further iterations. So once it's owned, it can't be
indexed by reference, leading to more clones
We need `current` to have _two_ possible lifetimes
1. `'out`: references derived from `&self`
2. `'local`: references derived from an owned value stored in a local
variable
```rust
enum MultiLife<'out, 'local, T>
where
'out: 'local,
T: ?Sized,
{
Out(&'out T),
Local(&'local T),
}
```
With `current: MultiLife<'out, '_, Value>`, we can traverse values with
minimal clones, and we can transform it to `Cow<'out, Value>` easily
(`MultiLife::Out -> Cow::Borrowed, MultiLife::Local -> Cow::Owned`) to
return it
# User-Facing Changes
# Tests + Formatting
# After Submitting
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
- A few days back I've got this idea regarding recalculus of width.
Now it calculates step by step.
So 1 loop over all data was removed.
All though there's full recalculation in case of `header_on_border`
😞 (can be fixed..... but I decided to be short)
In perfect world it also shall be refactored ......
- Also have done small refactoring to switch build table from
`Vec<Vec<_>>>` to table itself. To hide internals (kind of still there's
things which I don't like).
It touched the `--expand` algorithm lightly you can see the tests
changes.
- And when doing that noticed one more opportunity, to remove HashMap
usage and directly use `tabled::ColoredConfig`. Which reduces copy
operations and allocations.
- And fixed a small issue where trailing column being using deleted
column styles.
To conclude optimizations;
I did small testing and it's not slower.
But I didn't get the faster results either.
But I believe it must be faster well in all cases, I think maybe bigger
tables must be tested.
Maybe someone could have a few runs to compare performance.
cc: @fdncred
# Description
When first using `http get`, I was confused that all the examples used a
list for headers, leading me to believe this was the only way, and it
seemed a little weird having records in the language. Then, I found out
that you can indeed use record, so I changed the example to show this
behavior in a way users can find. There still is another examples that
uses a list so there should be no problem there.
# 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.
-->
remove j
<!--
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
<!-- 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 bumps reedline in nushell to the latest commit in the repo and
thiserror because it wouldn't compile without it, so that we can do some
quick testing to ensure there are no problems.
# 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.
-->
Replace example on `date now | debug` with `date now | format date
"%+"`. Add RFC3339 "%+" format string example on `format date`.
Users can now find how to format date-time to RFC3339.
FIXES: #15168
<!--
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.
-->
Documentation will now provide users examples on how to print RFC3339
strings.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Corrects documentation.
# 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 seeks to add a quality-of-life feature that enables date and
datetime parsing of strings in `polars into-df`, `polars into-lazy`, and
`polars open`, and avoid the more verbose method of casting each column
into date/datetime. Currently, setting the schema to `date` on a `str`
column would silently error as a null column. See a comparison of the
current and proposed implementations.
The proposed implementation assumes a date format "%Y-%m-%d" and a
datetime format of "%Y-%m-%d %H:%M:%S" for naive datetimes and "%Y-%m-%d
%H:%M:%S%:z" for timezone-aware datetimes. Other formats must be
specified via parsing through `polars as-date` and `polars as-datetime`.
```nushell
# Current Implementations
> [[a]; ["2025-04-01"]] | polars into-df --schema {a: date}
╭───┬───╮
│ # │ a │
├───┼───┤
│ 0 │ │
╰───┴───╯
> [[a]; ["2025-04-01 01:00:00"]] | polars into-df --schema {a: "datetime<ns,*>"}
╭───┬───╮
│ # │ a │
├───┼───┤
│ 0 │ │
╰───┴───╯
# Proposed Implementation
> [[a]; ["2025-04-01"]] | polars into-df --schema {a: date}
╭───┬─────────────────────╮
│ # │ a │
├───┼─────────────────────┤
│ 0 │ 04/01/25 12:00:00AM │
╰───┴─────────────────────╯
> [[a]; ["2025-04-01 01:00:00"]] | polars into-df --schema {a: "datetime<ns,*>"}
╭───┬─────────────────────╮
│ # │ a │
├───┼─────────────────────┤
│ 0 │ 04/01/25 01:00:00AM │
╰───┴─────────────────────╯
> [[a]; ["2025-04-01 01:00:00-04:00"]] | polars into-df --schema {a: "datetime<ns,UTC>"}
╭───┬─────────────────────╮
│ # │ a │
├───┼─────────────────────┤
│ 0 │ 04/01/25 05:00:00AM │
╰───┴─────────────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have the added option to parse string columns
into date/datetimes.
# 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 tests were added to any examples.
# 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 implements an experimental inter-job communication model,
through direct message passing, aka "mail"ing or "dm"ing:
- `job send <id>`: Sends a message the job with the given id, the root
job has id 0. Messages are stored in the recipient's "mailbox"
- `job recv`: Returns a stored message, blocks if the mailbox is empty
- `job flush`: Clear all messages from mailbox
Additionally, messages can be sent with a numeric tag, which can then be
filtered with `mail recv --tag`.
This is useful for spawning jobs and receiving messages specifically
from those jobs.
This PR is mostly a proof of concept for how inter-job communication
could look like, so people can provide feedback and suggestions
Closes #15199
May close#15220 since now jobs can access their own id.
# User-Facing Changes
Adds, `job id`, `job send`, `job recv` and `job flush` commands.
# Tests + Formatting
[X] TODO: Implement tests
[X] Consider rewriting some of the job-related tests to use this, to
make them a bit less fragile.
# After Submitting
# Description
Looks like `:nu` was forgotten about when the help system was
refactored.
# User-Facing Changes
# Tests + Formatting
# After Submitting
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
Fixes: #15510
I think it's introduced by #14653, which changes `and/or` to `match`
expression.
After looking into `compile_match`, it's important to collect the value
before matching this.
```rust
// Important to collect it first
builder.push(Instruction::Collect { src_dst: match_reg }.into_spanned(match_expr.span))?;
```
This pr is going to apply the logic while compiling `and/or` operation.
# User-Facing Changes
The following will raise a reasonable error:
```nushell
> (nu --testbin cococo false) and true
Error: nu:🐚:operator_unsupported_type
× The 'and' operator does not work on values of type 'string'.
╭─[entry #7:1:2]
1 │ (nu --testbin cococo false) and true
· ─┬ ─┬─
· │ ╰── does not support 'string'
· ╰── string
╰────
```
# Tests + Formatting
Added 1 test.
# After Submitting
Maybe need to update doc
https://github.com/nushell/nushell.github.io/pull/1876
---------
Co-authored-by: Stefan Holderbach <sholderbach@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.
-->
A friend of mine started using nushell on Windows and wondered why the
`cat` command wasn't available. I answered to him, that he can use `help
-f` or F1 to find the command but then we both realized that neither
`cat` nor `Get-Command` were part of `open`'s search terms. So I added
them.
# 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
> ```
-->
- 🟢 `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.
-->
The current implementation improperly inverts the conversion from
nanoseconds to the specified time units, resulting in nonsensical
Datetime and Duration parsing and integer overflows when the specified
time unit is not nanoseconds. This PR seeks to correct this conversion
by changing the multiplication to an integer division. Below are
examples highlighting the current and proposed implementations.
## Current Implementation
Specifying a different time unit incorrectly changes the returned value.
```nushell
> [[a]; [2024-04-01]] | polars into-df --schema {a: "datetime<ns,UTC>"}
╭───┬───────────────────────╮
│ # │ a │
├───┼───────────────────────┤
│ 0 │ 04/01/2024 12:00:00AM │
> [[a]; [2024-04-01]] | polars into-df --schema {a: "datetime<ms,UTC>"}
╭───┬───────────────────────╮
│ # │ a │
├───┼───────────────────────┤
│ 0 │ 06/27/2035 11:22:33PM │ <-- changing the time unit should not change the actual value
> [[a]; [1day]] | polars into-df --schema {a: "duration<ns>"}
╭───┬────────────────╮
│ # │ a │
├───┼────────────────┤
│ 0 │ 86400000000000 │
╰───┴────────────────╯
> [[a]; [1day]] | polars into-df --schema {a: "duration<ms>"}
╭───┬──────────────────────╮
│ # │ a │
├───┼──────────────────────┤
│ 0 │ -5833720368547758080 │ <-- i64 overflow
╰───┴──────────────────────╯
```
## Proposed Implementation
```nushell
> [[a]; [2024-04-01]] | polars into-df --schema {a: "datetime<ns,UTC>"}
╭───┬───────────────────────╮
│ # │ a │
├───┼───────────────────────┤
│ 0 │ 04/01/2024 12:00:00AM │
╰───┴───────────────────────╯
> [[a]; [2024-04-01]] | polars into-df --schema {a: "datetime<ms,UTC>"}
╭───┬───────────────────────╮
│ # │ a │
├───┼───────────────────────┤
│ 0 │ 04/01/2024 12:00:00AM │
╰───┴───────────────────────╯
> [[a]; [1day]] | polars into-df --schema {a: "duration<ns>"}
╭───┬────────────────╮
│ # │ a │
├───┼────────────────┤
│ 0 │ 86400000000000 │
╰───┴────────────────╯
> [[a]; [1day]] | polars into-df --schema {a: "duration<ms>"}
╭───┬──────────╮
│ # │ a │
├───┼──────────┤
│ 0 │ 86400000 │
╰───┴──────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No user-facing breaking change.
Developer breaking change: to mitigate the silent overflow in
nanoseconds conversion functions `nanos_from_timeunit` and
`nanos_to_timeunit` (new), the function signatures were changed from
`i64` to `Result<i64, ShellError>`.
# 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 additional examples were added, but I'd be happy to add a few if
needed. The covering tests just didn't fit well into any examples.
# 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 enables the option to set a column type to `decimal` in the
`--schema` parameter of `polars into-df` and `polars into-lazy`
commands. This option was already available in `polars open`, which used
the underlying polars io commands that already accounted for decimal
types when specified in the schema.
See below for a comparison of the current and proposed implementation.
```nushell
# Current Implementation
> [[a b]; [1 1.618]]| polars into-df -s {a: u8, b: 'decimal<4,3>'}
Error: × Error creating dataframe: Unsupported type: Decimal(Some(4), Some(3))
# Proposed Implementation
> [[a b]; [1 1.618]]| polars into-df -s {a: u8, b: 'decimal<4,3>'} | polars schema
╭───┬──────────────╮
│ a │ u8 │
│ b │ decimal<4,3> │
╰───┴──────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking change. Users has the new option to specify decimal in
`--schema` in `polars into-df` and `polars into-lazy`.
# 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
> ```
-->
An example in `polars into-df` was modified to showcase the decimal
type.
# 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
On Windows, I would like to be able to call a script directly in nushell
and have that script be found in the PATH and run based on filetype
associations and PATHEXT.
There have been previous discussions related to this feature, see
https://github.com/nushell/nushell/issues/6440 and
https://github.com/nushell/nushell/issues/15476. The latter issue is
only a few weeks old, and after taking a look at it and the resultant PR
I found that currently nushell is hardcoded to support only running
nushell (.nu) scripts in this way.
This PR seeks to make this functionality more generic. Instead of
checking that the file extension is explicitly `NU`, it instead checks
that it **is not** one of `COM`, `EXE`, `BAT`, `CMD`, or `PS1`. The
first four of these are extensions that Windows can figure out how to
run on its own. This is implied by the output of `ftype` for any of
these extensions, which shows that files are just run without a calling
command anyway.
```
>ftype batfile
batfile="%1" %*
```
PS1 files are ignored because they are handled as a special in later
logic.
In implementing this I initially tried to fetch the value of PATHEXT and
confirm that the file extension was indeed in PATHEXT. But I determined
that because `which()` respects PATHEXT, this would be redundant; any
executable that is found by `which` is already going to have an
extension in PATHEXT. It is thus only necessary to check that it isn't
one of the few extensions that should be called directly, without the
use of `cmd.exe`.
There are some small formatting changes to `run_external.rs` in the PR
as a result of running `cargo fmt` that are not entirely related to the
code I modified. I can back out those changes if that is desired.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Behavior for `.nu` scripts will not change. Users will still need to
ensure they have PATHEXT and filetype associations set correctly for
them to work, but this will now also apply to scripts of other types.
Fixes#14660
# Description
Fixed an issue where tables with empty values were incorrectly replaced
with [table X row] when converted to Markdown using the ```to md```
command.
Empty values are now replaced with whitespaces to preserve the original
table structure.
Additionally, fixed a missing newline (\n) between tables when using
--per-element in a list.
Removed (\n) from 2 examples for consistency.
Example:
```
For the list
let list = [ {name: bob, age: 21} {name: jim, age: 20} {name: sarah}]
Running "$list | to md --pretty" outputs:
| name | age |
| ----- | --- |
| bob | 21 |
| jim | 20 |
| sarah | |
------------------------------------------------------------------------------------------------
For the list
let list = [ {name: bob, age: 21} {name: jim, age: 20} {name: sarah} {name: timothy, age: 50} {name: paul} ]
Running "$list | to md --per-element --pretty" outputs:
| name | age |
| ------- | --- |
| bob | 21 |
| jim | 20 |
| timothy | 50 |
| name |
| ----- |
| sarah |
| paul |
```
# User-Facing Changes
The ```to md``` behaves as expected when piping a table that contains
empty values showing all rows and the empty items replaced with
whitespace.
# Tests + Formatting
Added 2 test cases to cover both issues.
fmt + clippy OK.
# After Submitting
The command documentation needs to be updated with an example for when
you want to "separate list into markdown tables"
# Description
I was playing around with the `debug` command and wanted to add this
information to it but since most of it already existed in `describe` I
wanted to try and add it here. It adds a few more details that are
hopefully helpful. It mainly tries to add the value type, rust datatype,
and value. I'm not sure all of this is wanted or needed but I thought it
was an interesting introspection idea.
### 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
Try to fixes https://github.com/nushell/nushell/issues/15326 in another
way.
The main point of this change is to avoid duplicate `write` and `close`
a redirected file. So during compile, if compiler know current element
is a sub-expression(defined by private `is_subexpression` function), it
will no longer invoke `finish_redirection`.
In this way, we can avoid duplicate `finish_redirection`.
# User-Facing Changes
`(^echo aa) o> /tmp/aaa` will no longer raise an error.
Here is the IR after the pr:
```
# 3 registers, 12 instructions, 11 bytes of data
# 1 file used for redirection
0: load-literal %1, string("aaa")
1: open-file file(0), %1, append = false
2: load-literal %1, glob-pattern("echo", no_expand = false)
3: load-literal %2, glob-pattern("true", no_expand = false)
4: push-positional %1
5: push-positional %2
6: redirect-out file(0)
7: redirect-err caller
8: call decl 135 "run-external", %0
9: write-file file(0), %0
10: close-file file(0)
11: return %0
```
# Tests + Formatting
Added 3 tests.
# After Submitting
Maybe need to update doc
https://github.com/nushell/nushell.github.io/pull/1876
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
Fixes#15559
# Description
The glob command wasn't working correctly with symlinks in the /sys
filesystem. This commit adds a new flag that allows users to explicitly
control whether symlinks should be followed, with special handling for
the /sys directory.
The issue was that the glob command didn't follow symbolic links when
traversing the /sys filesystem, resulting in an empty list even though
paths should be found. This implementation adds a new
`--follow-symlinks` flag that explicitly enables following symlinks. By
default, it now follows symlinks in most paths but has special handling
for /sys paths where the flag is required.
Example:
`
# Before: This would return an empty list on Linux systems
glob /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
# Now: This works as expected with the new flag
glob /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
--follow-symlinks
`
# User-Facing Changes
1. Added the --follow-symlinks (-l) flag to the glob command that allows
users to explicitly control whether symbolic links should be followed
2. Added a new example to the glob command help text demonstrating the
use of this flag
# Tests + Formatting
1. Added a test for the new --follow-symlinks flag
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
closes#15610 .
# 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 attempts to improve the performance of `std/log *` by making the
following changes:
1. use explicit piping instead of `reduce` for constructing the log
message
2. constify `log-level`, `log-ansi`, `log-types` etc.
3. use `.` instead of `get` to access `$env` fields
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Nothing.
# 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: Ben Yang <ben@ya.ng>
Co-authored-by: suimong <suimong@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.
-->
Contrary to the underlying implementation in polars rust/python, `polars
pivot` throws an error if the user tries to pivot on multiple columns of
different types. This PR seeks to remove this type-check. See comparison
below.
```nushell
# Current implementation: throws error when pivoting on multiple values of different types.
> [[name subject date test_1 test_2 grade_1 grade_2]; [Cady maths 2025-04-01 98 100 A A] [Cady physics 2025-04-01 99 100 A A] [Karen maths 2025-04-02 61 60 D D] [Karen physics 2025-04-02 58 60 D D]] | polars into-df | polars pivot --on [subject] --index [name] --values [test_1 grade_1]
Error: × Merge error
╭─[entry #291:1:271]
1 │ [[name subject date test_1 test_2 grade_1 grade_2]; [Cady maths 2025-04-01 98 100 A A] [Cady physics 2025-04-01 99 100 A A] [Karen maths 2025-04-02 61 60 D D] [Karen physics 2025-04-02 58 60 D D]] | polars into-df | polars pivot --on [subject] --index [name] --values [test_1 grade_1]
· ───────┬──────
· ╰── found different column types in list
╰────
help: datatypes i64 and str are incompatible
# Proposed implementation
> [[name subject date test_1 test_2 grade_1 grade_2]; [Cady maths 2025-04-01 98 100 A A] [Cady physics 2025-04-01 99 100 A A] [Karen maths 2025-04-02 61 60 D D] [Karen physics 2025-04-02 58 60 D D]] | polars into-df | polars pivot --on [subject] --index [name] --values [test_1 grade_1]
╭───┬───────┬──────────────┬────────────────┬───────────────┬─────────────────╮
│ # │ name │ test_1_maths │ test_1_physics │ grade_1_maths │ grade_1_physics │
├───┼───────┼──────────────┼────────────────┼───────────────┼─────────────────┤
│ 0 │ Cady │ 98 │ 99 │ A │ A │
│ 1 │ Karen │ 61 │ 58 │ D │ D │
╰───┴───────┴──────────────┴────────────────┴───────────────┴─────────────────╯
```
Additionally, this PR ports over the `separator` parameter in `pivot`,
which allows the user to specify how to delimit multiple `values` column
names:
```nushell
> [[name subject date test_1 test_2 grade_1 grade_2]; [Cady maths 2025-04-01 98 100 A A] [Cady physics 2025-04-01 99 100 A A] [Karen maths 2025-04-02 61 60 D D] [Karen physics 2025-04-02 58 60 D D]] | polars into-df | polars pivot --on [subject] --index [name] --values [test_1 grade_1] --separator /
╭───┬───────┬──────────────┬────────────────┬───────────────┬─────────────────╮
│ # │ name │ test_1/maths │ test_1/physics │ grade_1/maths │ grade_1/physics │
├───┼───────┼──────────────┼────────────────┼───────────────┼─────────────────┤
│ 0 │ Cady │ 98 │ 99 │ A │ A │
│ 1 │ Karen │ 61 │ 58 │ D │ D │
╰───┴───────┴──────────────┴────────────────┴───────────────┴─────────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Soft breaking change: where a user may have previously expected an error
(pivoting on multiple columns with different types), no error is thrown.
# 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 to `polars pivot`.
# 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!
-->
Fixes#15528
# Description
Fixed `kv set` passing the pipeline input to the closure instead of the
value stored in that key.
# User-Facing Changes
Now `kv set` will pass the value in that key to the closure.
# Tests + Formatting
# After Submitting
When combined with [the Cookbook
update](https://github.com/nushell/nushell.github.io/pull/1878), this
resolves#15452
# Description
When we removed the startup `ENV_CONVERSION` for path, as noted in the
issue above, we removed the ability for users to access this closure for
other purposes. This PR adds the PATH closures back as a `std` commands
that outputs a record of closures (similar to `ENV_CONVERSIONS`).
# User-Facing Changes
Doc will be updated and users can once again easily access `direnv`
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
Doc PR to be merged when released in 0.104
Fixes#13546
# Description
Previously, outer joins would remove rows without join columns, since
the "did not match" logic only executed when the row had the join
column.
To solve this, missing join columns are now treated the same as "exists
but did not match" cases. The logic now executes both when the join
column doesn't exist and when it exists but doesn't match, ensuring rows
without join columns are preserved. If the join column is not defined at
all, the previous behavior remains unchanged.
Example:
```
For the tables:
let left_side = [{a: a1 ref: 1} {a: a2 ref: 2} {a: a3}]
let right_side = [[b ref]; [b1 1] [b2 2] [b3 3]]
Running "$left_side | join -l $right_side ref" now outputs:
╭───┬────┬─────┬────╮
│ # │ a │ ref │ b │
├───┼────┼─────┼────┤
│ 0 │ a1 │ 1 │ b1 │
│ 1 │ a2 │ 2 │ b2 │
│ 2 │ a3 │ │ │
╰───┴────┴─────┴────╯
```
# User-Facing Changes
The ```join``` command will behave more similarly to SQL-style joins. In
this case, rows that lack the join column are preserved.
# Tests + Formatting
Added 2 test cases.
fmt + clippy OK.
# After Submitting
I don't believe anything is necessary.
# Description
Fixes: #14048
The issue happened when re-using a ***module file***, and the overlay
already has already saved `PWD`, then nushell restores the `PWD`
variable after activating it.
This pr is going to fix it by restoring `PWD` after re-using a module
file.
# User-Facing Changes
`overlay use spam.nu` will always keep `PWD`, if `spam.nu` itself
doesn't change `PWD` while activating.
# Tests + Formatting
Added 2 tests.
# After Submitting
NaN
# Description
This PR implements job tagging through the usage of a new `job tag`
command and a `--tag` for `job spawn`
Closes#15354
# User-Facing Changes
- New `job tag` command
- Job list may now have an additional `tag` column for the tag of jobs
(rows representing jobs without tags do not have this column filled)
- New `--tag` flag for `job spawn`
# Tests + Formatting
Integration tests are provided to test the newly implemented features
# After Submitting
Possibly document job tagging in the jobs documentation
# Description
Enable socks-proxy feature in ureq.
This allows use of socks protocol in proxy env variables when using
nushell http client.
eg. to use a socks5 proxy on localhost
```
ALL_PROXY=socks5://localhost:8080 http get ...
```
# User-Facing Changes
None
# Tests + Formatting
# After Submitting
Closes#15543
# Description
1. Simplify code in ``datetime.rs`` based on a suggestion in my last PR
on "datetime from record"
1. Make ``into duration`` work with durations inside a record, provided
as a cell path
1. Make ``into duration`` work with durations as record
# User-Facing Changes
```nushell
# Happy paths
~> {d: '1hr'} | into duration d
╭───┬─────╮
│ d │ 1hr │
╰───┴─────╯
~> {week: 10, day: 2, sign: '+'} | into duration
10wk 2day
# Error paths and invalid usage
~> {week: 10, day: 2, sign: 'x'} | into duration
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #4:1:26]
1 │ {week: 10, day: 2, sign: 'x'} | into duration
· ─┬─ ──────┬──────
· │ ╰── encountered here
· ╰── Invalid sign. Allowed signs are +, -
╰────
~> {week: 10, day: -2, sign: '+'} | into duration
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #5:1:17]
1 │ {week: 10, day: -2, sign: '+'} | into duration
· ─┬ ──────┬──────
· │ ╰── encountered here
· ╰── number should be positive
╰────
~> {week: 10, day: '2', sign: '+'} | into duration
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #6:1:17]
1 │ {week: 10, day: '2', sign: '+'} | into duration
· ─┬─ ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰────
~> {week: 10, unknown: 1} | into duration
Error: nu:🐚:unsupported_input
× Unsupported input
╭─[entry #7:1:1]
1 │ {week: 10, unknown: 1} | into duration
· ───────────┬────────── ──────┬──────
· │ ╰── Column 'unknown' is not valid for a structured duration. Allowed columns are: week, day, hour, minute, second, millisecond, microsecond, nanosecond, sign
· ╰── value originates from here
╰────
~> {week: 10, day: 2, sign: '+'} | into duration --unit sec
Error: nu:🐚:incompatible_parameters
× Incompatible parameters.
╭─[entry #2:1:33]
1 │ {week: 10, day: 2, sign: '+'} | into duration --unit sec
· ──────┬────── ─────┬────
· │ ╰── the units should be included in the record
· ╰── got a record as input
╰────
```
# Tests + Formatting
- Add examples and integration tests for ``into duration``
- Add one test for ``into duration``
# After Submitting
If this is merged in time, I'll update my PR on the "datetime handling
highlights" for the release notes.
Closes#12858
# Description
As explained in the ticket, easy to reproduce. Example: 1.07 minute is
1.07*60=64.2 secondes
```nushell
# before - wrong
> 1.07min
1min 4sec
# now - right
> 1.07min
1min 4sec 200ms
```
# User-Facing Changes
Bug is fixed when using ``into duration``.
# Tests + Formatting
Added a test for ``into duration``
Fixed ``parse_long_duration`` test: we gained precision 😄
# After Submitting
Release notes? Or blog is enough? Let me know
# Description
Fixes a regression caused by #15567, where I made the space detection in
command names switched from `get_span_content` to `get_decl().name()`,
which is slightly faster but it won't work in some cases:
e.g.
```nushell
use std/assert
assert equal
```
Reverted in this PR.
# User-Facing Changes
None
# Tests + Formatting
Refined
# 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 is a follow-up to the previous PR #15557 and part of a wider
campaign to enable certain polars commands that only operated on the
entire dataframe to also operate on expressions. Here, we enable two
commands `polars as-date` and `polars as-datetime` to receive
expressions as inputs so that they may be used on specific columns in a
dataframe with multiple columns of different types. See examples below.
```nushell
> [[a b]; ["2025-04-01" 1] ["2025-04-02" 2] ["2025-04-03" 3]] | polars into-df | polars select (polars col a | polars as-date %Y-%m-%d) b | polars collect
╭───┬───────────────────────┬───╮
│ # │ a │ b │
├───┼───────────────────────┼───┤
│ 0 │ 04/01/2025 12:00:00AM │ 1 │
│ 1 │ 04/02/2025 12:00:00AM │ 2 │
│ 2 │ 04/03/2025 12:00:00AM │ 3 │
╰───┴───────────────────────┴───╯
> seq date -b 2025-04-01 --periods 4 --increment 25min -o "%Y-%m-%d %H:%M:%S" | polars into-df | polars select (polars col 0 | polars as-datetime "%Y-%m-%d %H:%M:%S") | polars collect
╭───┬───────────────────────╮
│ # │ 0 │
├───┼───────────────────────┤
│ 0 │ 04/01/2025 12:00:00AM │
│ 1 │ 04/01/2025 12:25:00AM │
│ 2 │ 04/01/2025 12:50:00AM │
│ 3 │ 04/01/2025 01:15:00AM │
╰───┴───────────────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have the additional option to use `polars
as-date` and `polars as-datetime` in expressions that operate on
specific columns.
# 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 have been added to `polars as-date` and `polars as-datetime`.
# 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 an issue where, for custom values, the `//` operator was
incorrectly mapped to `Math::Divide` instead of `Math::FloorDivide`.
This PR also fixes the same mis-mapping in the `polars` plugin.
```nushell
> [[a b c]; [x 1 1.1] [y 2 2.2] [z 3 3.3]] | polars into-df | polars select {div: ((polars col c) / (polars col b)), floor_div: ((polars col c) // (polars col b))} | polars collect
╭───┬───────┬───────────╮
│ # │ div │ floor_div │
├───┼───────┼───────────┤
│ 0 │ 1.100 │ 1.000 │
│ 1 │ 1.100 │ 1.000 │
│ 2 │ 1.100 │ 1.000 │
╰───┴───────┴───────────╯
```
**Note:** the number of line changes in this PR is inflated because of
auto-formatting in `nu_plugin_polars/Cargo.toml`. Substantively, I've
only added the `round_series` feature to the polars dependency list.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Breaking change: users who expected the operator `//` to function the
same as `/` for custom values will not get the expected result.
# 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 tests were yet added, but let me know if we should put something into
one of the polars examples.
# 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 the exponent operator ("**") to polars expressions.
```nushell
> [[a b]; [6 2] [4 2] [2 2]] | polars into-df | polars select a b {c: ((polars col a) ** 2)}
╭───┬───┬───┬────╮
│ # │ a │ b │ c │
├───┼───┼───┼────┤
│ 0 │ 6 │ 2 │ 36 │
│ 1 │ 4 │ 2 │ 16 │
│ 2 │ 2 │ 2 │ 4 │
╰───┴───┴───┴────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users are enabled to use the `**` operator in
polars expressions.
# 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
> ```
-->
An example in `polars select` was modified to showcase the `**`
operator.
# 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 adds a new option `--raw-value`/`-v` to the `debug` command to
allow you to only get the debug string part of the nushell value.
Because, sometimes you don't need the span or nushell datatype and you
just want the val part.
You can see the difference between `debug -r` and `debug -v` here.
It should work on all datatypes except Value::Error and Value::Closure.
# 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 seeks to expand `polars col` functionality to allow selecting
multiple columns and columns by type, which is particularly useful when
piping to subsequent expressions that should be applied to each column
selected (e.g., `polars col int --type | polars sum` as a shorthand for
`[(polars col a | polars sum), (polars col b | polars sum)]`). See
examples below.
```nushell
# Select multiple columns (cannot be used with asterisk wildcard)
> [[a b c]; [x 1 1.1] [y 2 2.2] [z 3 3.3]] | polars into-df
| polars select (polars col b c | polars sum) | polars collect
╭───┬───┬──────╮
│ # │ b │ c │
├───┼───┼──────┤
│ 0 │ 6 │ 6.60 │
╰───┴───┴──────╯
# Select multiple columns by types (cannot be used with asterisk wildcard)
> [[a b c]; [x o 1.1] [y p 2.2] [z q 3.3]] | polars into-df
| polars select (polars col str f64 --type | polars max) | polars collect
╭───┬───┬───┬──────╮
│ # │ a │ b │ c │
├───┼───┼───┼──────┤
│ 0 │ z │ q │ 3.30 │
╰───┴───┴───┴──────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have the additional capability to select
multiple columns in `polars col`.
# 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 have been added to `polars col`.
# 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 this PR I added the flag `--plugins` to the `testing.nu` file inside
of `crates/nu-std`. This allows running tests with active plugins. While
I did not use it here in this repo, it allows testing in
[nushell/plugin-examples](https://github.com/nushell/plugin-examples)
with plugins.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
None, just the additional flag.
# 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`
(nothing broke \o/)
# 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
<!--
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 lifts the constraint that expressions in the `polars group-by`
command must be limited only to the type `Expr::Column` rather than most
`Expr` types, which is what the underlying polars crate allows. This
change enables more complex expressions to group by.
In the example below, we group by even or odd days of column `a`. While
we can reach the same result by creating and grouping by a new column in
two separate steps, integrating these steps in a single group-by allows
for better delegation to the polars optimizer.
```nushell
# Group by an expression and perform an aggregation
> [[a b]; [2025-04-01 1] [2025-04-02 2] [2025-04-03 3] [2025-04-04 4]]
| polars into-lazy
| polars group-by (polars col a | polars get-day | $in mod 2)
| polars agg [
(polars col b | polars min | polars as "b_min")
(polars col b | polars max | polars as "b_max")
(polars col b | polars sum | polars as "b_sum")
]
| polars collect
| polars sort-by a
╭───┬───┬───────┬───────┬───────╮
│ # │ a │ b_min │ b_max │ b_sum │
├───┼───┼───────┼───────┼───────┤
│ 0 │ 0 │ 2 │ 4 │ 6 │
│ 1 │ 1 │ 1 │ 3 │ 4 │
╰───┴───┴───────┴───────┴───────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. The user is empowered to use more complex
expressions in `polars group-by`
# 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
> ```
-->
An example is added to `polars group-by`.
# 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 directly ports the polars function `polars.Expr.dt.truncate`
(https://docs.pola.rs/api/python/stable/reference/expressions/api/polars.Expr.dt.truncate.html),
which rounds a datetime to an arbitrarily specified period length. This
function is particularly useful when rounding to variable period lengths
such as months or quarters. See below for examples.
```nushell
# Truncate a series of dates by period length
> seq date -b 2025-01-01 --periods 4 --increment 6wk -o "%Y-%m-%d %H:%M:%S" | polars into-df | polars as-datetime "%F %H:%M:%S" --naive | polars select datetime (polars col datetime | polars truncate 5d37m | polars as truncated) | polars collect
╭───┬───────────────────────┬───────────────────────╮
│ # │ datetime │ truncated │
├───┼───────────────────────┼───────────────────────┤
│ 0 │ 01/01/2025 12:00:00AM │ 12/30/2024 04:49:00PM │
│ 1 │ 02/12/2025 12:00:00AM │ 02/08/2025 09:45:00PM │
│ 2 │ 03/26/2025 12:00:00AM │ 03/21/2025 02:41:00AM │
│ 3 │ 05/07/2025 12:00:00AM │ 05/05/2025 08:14:00AM │
╰───┴───────────────────────┴───────────────────────╯
# Truncate based on period length measured in quarters and months
> seq date -b 2025-01-01 --periods 4 --increment 6wk -o "%Y-%m-%d %H:%M:%S" | polars into-df | polars as-datetime "%F %H:%M:%S" --naive | polars select datetime (polars col datetime | polars truncate 1q5mo | polars as truncated) | polars collect
╭───┬───────────────────────┬───────────────────────╮
│ # │ datetime │ truncated │
├───┼───────────────────────┼───────────────────────┤
│ 0 │ 01/01/2025 12:00:00AM │ 09/01/2024 12:00:00AM │
│ 1 │ 02/12/2025 12:00:00AM │ 09/01/2024 12:00:00AM │
│ 2 │ 03/26/2025 12:00:00AM │ 09/01/2024 12:00:00AM │
│ 3 │ 05/07/2025 12:00:00AM │ 05/01/2025 12:00:00AM │
╰───┴───────────────────────┴───────────────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. This PR introduces a new command `polars truncate`
# 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
> ```
-->
Example test was 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.
-->
Bumps [rust-embed](https://github.com/pyros2097/rust-embed) from 8.6.0
to 8.7.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.7.0] - 2025-04-10</h2>
<ul>
<li>add deterministic timestamps flag for deterministic builds <a
href="https://redirect.github.com/pyrossh/rust-embed/pull/259">#259</a>.
Thanks to <a href="https://github.com/daywalker90">daywalker90</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>
Bumps [data-encoding](https://github.com/ia0/data-encoding) from 2.8.0
to 2.9.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4fce77c46b"><code>4fce77c</code></a>
Release 2.9.0 (<a
href="https://redirect.github.com/ia0/data-encoding/issues/138">#138</a>)</li>
<li><a
href="d81616352a"><code>d816163</code></a>
Add encode_mut_str to guarantee UTF-8 for safe callers (<a
href="https://redirect.github.com/ia0/data-encoding/issues/137">#137</a>)</li>
<li><a
href="ec53217669"><code>ec53217</code></a>
Update doc badge in README.md (<a
href="https://redirect.github.com/ia0/data-encoding/issues/135">#135</a>)</li>
<li>See full diff in <a
href="https://github.com/ia0/data-encoding/compare/v2.8.0...v2.9.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>
Fixes a bug caused by #15536
Sorry about that, @fdncred
# Description
I've made the panic reproducible in the test case.
TLDR: completer will sometimes return new decl_ids outside of the range
of the engine_state passed in.
# User-Facing Changes
bug fix
# Tests + Formatting
+1
# After Submitting
# Description
Performing a `polars collect` on an eager dataframe should be a no-op
operation. However, when used with a pipeline and not saving to a value
a cache error occurs. This addresses that cache error.
# Description
This updates `string_expand()` in nu-table's util.rs to use the
`std::iter` library's `repeat_n()` function, which was suggested as a
more readable version of the existing `repeat().take()` implementation.
# User-Facing Changes
Should have no user facing changes.
# Tests + Formatting
All green circles!
```
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib
```
<!--
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 bug where various commands that cast a column as a
`date` type would return `datetime<ns>` rather than the intended type
`date`. Affected commands include `polars into-df --schema`, `polars
into-lazy --schema`, `polars as-date`, and `polars cast date`.
This bug derives from the fact that Nushell uses the `date` type to
denote a datetime type whereas polars differentiates between `Date` and
`Datetime` types. By default, this PR retains the behavior that a
Nushell `date` type will be mapped to a polars `Datetime<ns>` unless
otherwise specified.
```nushell
# Current (erroneous) implementation
> [[a]; [2025-03-20]] | polars into-df --schema {a: "date"} | polars schema
╭───┬──────────────╮
│ a │ datetime<ns> │
╰───┴──────────────╯
# Fixed implementation
> [[a]; [2025-03-20]] | polars into-df --schema {a: "date"} | polars schema
╭───┬──────╮
│ a │ date │
╰───┴──────╯
# Fixed implementation: by default, Nushell dates map to datetime<ns>
> [[a]; [2025-03-20]] | polars into-df | polars schema
╭───┬───────────────────╮
│ a │ datetime<ns, UTC> │
╰───┴───────────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Soft breaking change: users previously who wanted to cast a date column
to type `date` can now expect the output to be type `date` instead of
`datetime<ns>`.
# 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
> ```
-->
Example test added to `polars as-date` command.
# 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 be more performant, calling for `find_decl` by name for all
entries is generally a heavy op.
# User-Facing Changes
NA
# Tests + Formatting
# After Submitting
# Description
Mainly performance improvement of lsp operations involving flat_map on
AST nodes.
Previous flat_map traversing is functional, which is a nice property to
have, but the heavy cost of vector collection on each tree node makes it
undesirable.
This PR mitigates the problem with a mutable accumulator.
# User-Facing Changes
Should be none.
# Tests + Formatting
# After Submitting
# Description
`config nu/env` used to ignore the frozen wait job status response and
did not add processes to the job table when they were frozen.
This PR refactors the PostWaitCallback used in run_external and allows
frozen processes spawned by `config_.rs` to be added to the job table.
Closes#15389
# User-Facing Changes
`config nu` now respects the job freezing semantics.
# Tests + Formatting
This behavior can be verified by running `config nu` or `config env`,
hitting Ctrl-Z, and then running `job list`.
# Description
Output type of `polars schema` signature output type is of dataframe. It
should be of type record.
# User-Facing Changes
- `polars schema` - how has an output type of record
<!--
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 simplify the syntax for commands that handle a list of
expressions (e.g., `select`, `with-column`, and `agg`) by enabling the
user to replace a list of expressions each aliased with `polars as` to a
single record where the key is the alias for the value. See below for
examples in several contexts.
```nushell
# Select a column from a dataframe using a record
> [[a b]; [6 2] [4 2] [2 2]] | polars into-df | polars select {c: ((polars col a) * 2)}
╭───┬────╮
│ # │ c │
├───┼────┤
│ 0 │ 12 │
│ 1 │ 8 │
│ 2 │ 4 │
╰───┴────╯
# Select a column from a dataframe using a mix of expressions and record of expressions
> [[a b]; [6 2] [4 2] [2 2]] | polars into-df | polars select a b {c: ((polars col a) * 2)}
╭───┬───┬───┬────╮
│ # │ a │ b │ c │
├───┼───┼───┼────┤
│ 0 │ 6 │ 2 │ 12 │
│ 1 │ 4 │ 2 │ 8 │
│ 2 │ 2 │ 2 │ 4 │
╰───┴───┴───┴────╯
# Add series to the dataframe using a record
> [[a b]; [1 2] [3 4]]
| polars into-lazy
| polars with-column {
c: ((polars col a) * 2)
d: ((polars col a) * 3)
}
| polars collect
╭───┬───┬───┬───┬───╮
│ # │ a │ b │ c │ d │
├───┼───┼───┼───┼───┤
│ 0 │ 1 │ 2 │ 2 │ 3 │
│ 1 │ 3 │ 4 │ 6 │ 9 │
╰───┴───┴───┴───┴───╯
# Group by and perform an aggregation using a record
> [[a b]; [1 2] [1 4] [2 6] [2 4]]
| polars into-lazy
| polars group-by a
| polars agg {
b_min: (polars col b | polars min)
b_max: (polars col b | polars max)
b_sum: (polars col b | polars sum)
}
| polars collect
| polars sort-by a
╭───┬───┬───────┬───────┬───────╮
│ # │ a │ b_min │ b_max │ b_sum │
├───┼───┼───────┼───────┼───────┤
│ 0 │ 1 │ 2 │ 4 │ 6 │
│ 1 │ 2 │ 4 │ 6 │ 10 │
╰───┴───┴───────┴───────┴───────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users now can use a mix of lists of expressions and
records of expressions where previously only lists of expressions were
accepted (e.g., in `select`, `with-column`, and `agg`).
# 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
> ```
-->
Example tests were added to `select`, `with-column`, and `agg`.
# 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 'job' command was incorrectly placed into the "Strings" category
rather than the "Experimental" category like its subcommands. This PR
resolves that issues.
# User-Facing Changes
Changes to where the `job` command is found when using the `help`
command or reading the 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.
-->
Introducing a basic implementation of the polars expression for window
functions: `over`
(https://docs.pola.rs/api/python/stable/reference/expressions/api/polars.Expr.over.html).
Note that this PR only implements the default values for the sorting and
`mapping_strategy` parameters. Implementations for other values for
these parameters may be added in a future PR, as the demand arises.
```nushell
# Compute expression over an aggregation window
> [[a b]; [x 2] [x 4] [y 6] [y 4]]
| polars into-lazy
| polars select a (polars col b | polars cumulative sum | polars over a | polars as cum_b)
| polars collect
╭───┬───┬───────╮
│ # │ a │ cum_b │
├───┼───┼───────┤
│ 0 │ x │ 2 │
│ 1 │ x │ 6 │
│ 2 │ y │ 6 │
│ 3 │ y │ 10 │
╰───┴───┴───────╯
# Compute expression over an aggregation window where partitions are defined by expressions
> [[a b]; [x 2] [X 4] [Y 6] [y 4]]
| polars into-lazy
| polars select a (polars col b | polars cumulative sum | polars over (polars col a | polars lowercase) | polars as cum_b)
| polars collect
╭───┬───┬───────╮
│ # │ a │ cum_b │
├───┼───┼───────┤
│ 0 │ x │ 2 │
│ 1 │ X │ 6 │
│ 2 │ Y │ 6 │
│ 3 │ y │ 10 │
╰───┴───┴───────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. This PR seeks to add a new command only.
# 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
> ```
-->
Example tests are included.
# 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 updates the following functions so they may also be used in a
polars expression:
- `polars get-day`
- `polars get-hour`
- `polars get-minute`
- `polars get-month`
- `polars get-nanosecond`
- `polars get-ordinal`
- `polars get-second`
- `polars get-week`
- `polars get-weekday`
- `polars get-year`
Below examples provide a comparison of the two contexts in which each of
these commands may be used:
```nushell
# Returns day from a date (current use case)
> let dt = ('2020-08-04T16:39:18+00:00' | into datetime --timezone 'UTC');
let df = ([$dt $dt] | polars into-df);
$df | polars get-day
╭───┬───╮
│ # │ 0 │
├───┼───┤
│ 0 │ 4 │
│ 1 │ 4 │
╰───┴───╯
# Returns day from a date in an expression (additional use case provided by this PR)
> let dt = ('2020-08-04T16:39:18+00:00' | into datetime --timezone 'UTC');
let df = ([$dt $dt] | polars into-df);
$df | polars select (polars col 0 | polars get-day)
╭───┬───╮
│ # │ 0 │
├───┼───┤
│ 0 │ 4 │
│ 1 │ 4 │
╰───┴───╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Each of these functions retains its current
behavior and gains the benefit that they can now be used in an
expression as well.
# 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
> ```
-->
Tests have been added to each of the examples.
# 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 seeks to expand `polars lit` to handle additional nushell types:
Value::Date and Value::Duration. This change is especially relevant to
the `polars filter` command, where expressions would then directly
incorporate Value::Date and Value::Duration types as literals. See one
such example below.
```nushell
# Filter dataframe for rows where dt is within the last 2 days of the maximum dt value
> [[dt val]; [2025-04-01 1] [2025-04-02 2] [2025-04-03 3] [2025-04-04 4]] | polars into-df | polars filter ((polars col dt) > ((polars col dt | polars max | $in - 2day)))
╭───┬─────────────────────┬─────╮
│ # │ dt │ val │
├───┼─────────────────────┼─────┤
│ 0 │ 04/03/25 12:00:00AM │ 3 │
│ 1 │ 04/04/25 12:00:00AM │ 4 │
╰───┴─────────────────────┴─────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users now can directly access Value::Date and
Value::Duration types as literals in polars expressions.
# 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
> ```
-->
Several additional examples added to `polars lit` and `polars filter`
# 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 changes the signature of `kill` from `kill pid ...rest` to `kill
...pid`.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Users will now be able to spread a list of pids to the `kill` command,
whereas they'd have to specify the first separately before.
# 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 direct port of the python polars command `convert_time_zone`
(https://docs.pola.rs/api/python/stable/reference/series/api/polars.Series.dt.convert_time_zone.html).
Consistent with the rust/python implementation, naive datetimes are
treated as if they are in UTC time.
```nushell
# Convert timezone for timezone-aware datetime
> ["2025-04-10 09:30:00 -0400" "2025-04-10 10:30:00 -0400"] | polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S %z"
| polars select (polars col datetime | polars convert-time-zone "Europe/Lisbon")
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 04/10/2025 02:30:00PM │
│ 1 │ 04/10/2025 03:30:00PM │
╰───┴───────────────────────╯
# Timezone conversions for timezone-naive datetime will assume the original timezone is UTC
> ["2025-04-10 09:30:00" "2025-04-10 10:30:00"] | polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
| polars select (polars col datetime | polars convert-time-zone "America/New_York")
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 04/10/2025 05:30:00AM │
│ 1 │ 04/10/2025 06:30:00AM │
╰───┴───────────────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have access to a new command `polars
convert-time-zone`
# 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
> ```
-->
Example tests have been 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.
-->
Closes #13972
# Description
First commit: a hotfix concerning my last PR #15544! I had a
``unwrap_or_default`` that resulted in all years before ~1800 being
considered as "now", because the ``num_nanoseconds()`` overflowed.
Cc @fdncred
Second: about #13972
Negative years are not allowed with RFC 2822 formatting, so I fallback
RTC 3339 in such cases.
If you want you might Rebase and Merge, and not squash.
# User-Facing Changes
On master 🔴 :
```nu
~> {year: 1900} | into datetime
Mon, 1 Jan 1900 00:00:00 +0200 (125 years ago)
# OK
~> {year: 1000} | into datetime
Wed, 1 Jan 1000 00:00:00 +0200 (now)
# NOT OK: now?
~> {year: -1000} | into datetime
-1000-01-01T00:00:00+02:00 (now)
# NOT OK: now?
~> {year: -1000} | into datetime | format date
Error: × Main thread panicked.
├─▶ at C:\Users\RIL1RT\.cargo\registry\src\index.crates.io-6f17d22bba15001f\chrono-0.4.39\src\datetime\mod.rs:626:14
╰─▶ writing rfc2822 datetime to string should never fail: Error
help: set the `RUST_BACKTRACE=1` environment variable to display a backtrace.
# NOT OK: panics
```
On this branch 🟢 :
```nu
~> {year: 1900} | into datetime
Mon, 1 Jan 1900 00:00:00 +0200 (in 125 years)
~> {year: 1000} | into datetime
Wed, 1 Jan 1000 00:00:00 +0200 (1025 years ago)
~> {year: -1000} | into datetime
-1000-01-01T00:00:00+02:00 (3025 years ago)
~> {year: -1000} | into datetime | format date
-1000-01-01T00:00:00+02:00
~> '3000 years ago' | date from-human | format date
-0975-04-11T18:18:24.301641100+02:00
```
# Tests + Formatting
# After Submitting
Nothing required IMO
<!--
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 add a direct port of the python polars
`replace_time_zone` command in the `dt` namespace
(https://docs.pola.rs/api/python/stable/reference/series/api/polars.Series.dt.replace_time_zone.html).
Please note: I opted for two keywords "dt" and "replace-time-zone" to
map directly with the implementation in both the rust and python
packages, but I'm open to simplifying it to just one keyword, or `polars
replace-time-zone`
```nushell
# Apply timezone to a naive datetime
> ["2021-12-30 00:00:00" "2021-12-31 00:00:00"] | polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
| polars select (polars col datetime | polars dt replace-time-zone "America/New_York")
╭───┬─────────────────────╮
│ # │ datetime │
├───┼─────────────────────┤
│ 0 │ 12/30/21 12:00:00AM │
│ 1 │ 12/31/21 12:00:00AM │
╰───┴─────────────────────╯
# Apply timezone with ambiguous datetime
> ["2025-11-02 00:00:00", "2025-11-02 01:00:00", "2025-11-02 02:00:00", "2025-11-02 03:00:00"]
| polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
| polars select (polars col datetime | polars dt replace-time-zone "America/New_York" --ambiguous null)
╭───┬─────────────────────╮
│ # │ datetime │
├───┼─────────────────────┤
│ 0 │ 11/02/25 12:00:00AM │
│ 1 │ │
│ 2 │ 11/02/25 02:00:00AM │
│ 3 │ 11/02/25 03:00:00AM │
╰───┴─────────────────────╯
# Apply timezone with nonexistent datetime
> ["2025-03-09 01:00:00", "2025-03-09 02:00:00", "2025-03-09 03:00:00", "2025-03-09 04:00:00"]
| polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
| polars select (polars col datetime | polars dt replace-time-zone "America/New_York" --nonexistent null)
╭───┬─────────────────────╮
│ # │ datetime │
├───┼─────────────────────┤
│ 0 │ 03/09/25 01:00:00AM │
│ 1 │ │
│ 2 │ 03/09/25 03:00:00AM │
│ 3 │ 03/09/25 04:00:00AM │
╰───┴─────────────────────╯
```
# User-Facing Changes
No breaking changes. The user will be able to access the new command.
# Tests + Formatting
See example tests.
# After Submitting
This addresses color issue; Yeees just got forgotten it :(
As far as I understand an acceptance test can't be created because ansi
got stripped in `nu!`. (for future regressions)
But wrapping I need to take a deeper look.
Maybe in an hour.
cc: @fdncred
Hi,
This PR should close 3 issues
- [DMY date format is parsed inconsistently
#14123](https://github.com/nushell/nushell/issues/14123)
- [into datetime doesnt't work with --format and ignores user's locale
#11015](https://github.com/nushell/nushell/issues/11015)
- [into datetime: iinconsistent and incrrect behaviour regarding
timezones #13823](https://github.com/nushell/nushell/issues/13823)
# Description
- Allow to parse only dates or only times with --format
- Use local timezone depending on the input. Ex: I'm in France, so show
dates with +0100 in winter and +0200 in summer.
```nushell
# Concerning #13823
> "2020-01-01 12:00" | into datetime
Wed, 1 Jan 2020 12:00:00 +0100 (5 years ago)
# OK, it's my timezone in winter time
> "2020-06-01 12:00" | into datetime
Mon, 1 Jun 2020 12:00:00 +0200 (4 years ago)
# OK, it's my timezone in summertime
> ("2024-10-27 12:00" | into datetime) - ("2024-10-27 00:00" | into datetime)
13hr
# Ok, because we switched from summer to winter time on 2025-10-27, so there are actually 13h between midnight and noon
> "2020-01-01 12:00" | into datetime --format "%Y-%m-%d %H:%M"
Wed, 1 Jan 2020 12:00:00 +0100 (5 years ago)
# OK: timezone is assumed to be local, and +0100 is my timezone in winter
# Concerning #14123 and #11015
# Flexible parsing still works like before, which could be counter-intuitive, but it's flexible parsing
# with one difference: the timezone is local
> '12-01-2001' | into datetime
Sat, 1 Dec 2001 00:00:00 +0100 (23 years ago)
# OK, +0100 is my timezone in winter time. If I run it with nushell 0.103.0 in summer time, I get +0200
> '13-01-2001' | into datetime
Sat, 13 Jan 2001 00:00:00 +0100 (24 years ago)
## If you want, you can use the --format option to parse a date or a time (before, it had to be a date + time)
## Notice here again the timezone is correct depending on winter/summer time
~> "06.03.2023" | into datetime -f "%d.%m.%Y"
Mon, 6 Mar 2023 00:00:00 +0100 (2 years ago)
~> "06.03.2023" | into datetime -f "%m.%d.%Y"
Sat, 3 Jun 2023 00:00:00 +0200 (2 years ago)
> "10:00" | into datetime --format "%H:%M"
Thu, 10 Apr 2025 10:00:00 +0200 (9 hours ago)
```
# User-Facing Changes
See above
# Tests + Formatting
# After Submitting
I'll down something for the release notes, if this is merged in 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.
-->
This PR should close#15474 .
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
When users set the match algorithm to 'substring' by modifying
`$env.config` to `$env.config.completions.algorithm = "substring"``),
completions are done based on substring matches.
This was previously possible by setting `positional` to be false in
custom completers, but doing so now logs a warning as this feature is
set to be deprecated and replaced by the new way of setting the matching
algorithm to substring based.
# Description
Introduces `polars into-schema` which allows converting Values such as
records to a schema. This implicitly happens when when passing records
into commands like `polars into-df` today. This allows you to convert to
a schema object ahead of time and reuse the schema object. This can be
useful for guaranteeing your schema object is correct.
```nu
> ❯ : let schema = ({name: str, type: str} | polars into-schema)
> ❯ : ls | select name type | polars into-lazy -s $schema | polars schema
╭──────┬─────╮
│ name │ str │
│ type │ str │
╰──────┴─────╯
```
# User-Facing Changes
- Introduces `polars into-schema` allowing records to be converted to
schema objects.
Issue #12289, can be closed when this is merged
# Description
Currently, the ``into datetime`` command's signature indicates that it
supports input as record, but it was actually not supported.
This PR implements this feature.
# User-Facing Changes
``into datetime``'s signature changed (see comments)
**Happy paths**
Note: I'm in +02:00 timezone.
```nushell
> date now | into record | into datetime
Fri, 4 Apr 2025 18:32:34 +0200 (now)
> {year: 2025, month: 12, day: 6, second: 59} | into datetime | into record
╭─────────────┬────────╮
│ year │ 2025 │
│ month │ 12 │
│ day │ 6 │
│ hour │ 0 │
│ minute │ 0 │
│ second │ 59 │
│ millisecond │ 0 │
│ microsecond │ 0 │
│ nanosecond │ 0 │
│ timezone │ +02:00 │
╰─────────────┴────────╯
> {day: 6, second: 59, timezone: '-06:00'} | into datetime | into record
╭─────────────┬────────╮
│ year │ 2025 │
│ month │ 4 │
│ day │ 6 │
│ hour │ 0 │
│ minute │ 0 │
│ second │ 59 │
│ millisecond │ 0 │
│ microsecond │ 0 │
│ nanosecond │ 0 │
│ timezone │ -06:00 │
╰─────────────┴────────╯
```
**Edge cases**
```nushell
{} | into datetime
Fri, 4 Apr 2025 18:35:19 +0200 (now)
```
**Error paths**
- A key has a wrong type
```nushell
> {month: 12, year: '2023'} | into datetime
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #8:1:19]
1 │ {month: 12, year: '2023'} | into datetime
· ───┬── ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰────
```
```nushell
> {month: 12, year: 2023, timezone: 100} | into datetime
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #10:1:35]
1 │ {month: 12, year: 2023, timezone: 100} | into datetime
· ─┬─ ──────┬──────
· │ ╰── only string input data is supported
· ╰── input type: int
╰────
```
- Key has the right type but value invalid (e.g. month=13, or day=0)
```nushell
> {month: 13, year: 2023} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #9:1:1]
1 │ {month: 13, year: 2023} | into datetime
· ───────────┬─────────── ──────┬──────
· │ ╰── one of more values are incorrect and do not represent valid date
· ╰── encountered here
╰────
```
```nushell
> {hour: 1, minute: 1, second: 70} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #3:1:1]
1 │ {hour: 1, minute: 1, second: 70} | into datetime
· ────────────────┬─────────────── ──────┬──────
· │ ╰── one of more values are incorrect and do not represent valid time
· ╰── encountered here
╰────
```
- Timezone has right type but is invalid
```nushell
> {month: 12, year: 2023, timezone: "+100:00"} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #11:1:35]
1 │ {month: 12, year: 2023, timezone: "+100:00"} | into datetime
· ────┬──── ──────┬──────
· │ ╰── encountered here
· ╰── invalid timezone
╰────
```
- Record contains an invalid key
```nushell
> {month: 12, year: 2023, unknown: 1} | into datetime
Error: nu:🐚:unsupported_input
× Unsupported input
╭─[entry #12:1:1]
1 │ {month: 12, year: 2023, unknown: 1} | into datetime
· ─────────────────┬───────────────── ──────┬──────
· │ ╰── Column 'unknown' is not valid for a structured datetime. Allowed
columns are: year, month, day, hour, minute, second, millisecond,
microsecond, nanosecond, timezone
· ╰── value originates from here
╰────
```
- If several issues are present, the user can get the error msg for only
one, though
```nushell
> {month: 20, year: '2023'} | into datetime
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #7:1:19]
1 │ {month: 20, year: '2023'} | into datetime
· ───┬── ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰
```
# Tests + Formatting
Tests added
Fmt + clippy OK
# After Submitting
Maybe indicate that in the release notes
I added an example in the command, so the documentation will be
automatically updated.
# Description
This PR tries to fix the datetime-diff custom command so that it
includes ms, us, ns.
Difference in the banner in 2 separate starts.
### Old
```nushell
It's been this long since Nushell's first commit:
5yrs 10months 29days 9hrs 1min 47secs
```
### New
```nushell
It's been this long since Nushell's first commit:
5yrs 10months 29days 9hrs 1min 22secs 49ms 885µs
```
There should be ns above on the new one, not sure why there isn't. It
could have something to do with how the banner works but i'll save that
for another PR.
🤔 It could be because there are no fractional seconds in the math?
`datetime-diff (date now) 2019-05-10T09:59:12-07:00`. However, I'm not
sure why `date now` has no nanoseconds. Oh, wait. I think that's because
MacOS doesn't have nanosecond precision?
```
❯ ^date +%s.%N
1744251636.365003000
```
Closes https://github.com/nushell/nushell/issues/15524
/cc @NotTheDr01ds
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
I've made the panic reproducible in test case
`workspace::tests::quoted_command_reference_in_workspace`.
This PR fixes that by parsing + merging 1 more time, IMO it's a small
price to pay for workspace-wide heavy requests.
# User-Facing Changes
bug fix
# Tests + Formatting
made 1 case harder
# After Submitting
# Description
This pull request does a lot of the heavy lifting needed to supported
more complex dtypes like categorical dtypes. It introduces a new
CustomValue, NuDataType and makes NuSchema a full CustomValue. Further
more it introduces a new command `polars into-dtype` that allows a dtype
to be created. This can then be passed into schemas when they are
created.
```nu
> ❯ : let dt = ("str" | polars to-dtype)
> ❯ : [[a b]; ["one" "two"]] | polars into-df -s {a: $dt, b: str} | polars schema
╭───┬─────╮
│ a │ str │
│ b │ str │
╰───┴─────╯
```
# User-Facing Changes
- Introduces new command `polars into-dtype`, allows dtype variables to
be passed in during schema creation.
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.44.1 to 1.44.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tokio-rs/tokio/releases">tokio's
releases</a>.</em></p>
<blockquote>
<h2>Tokio v1.44.2</h2>
<p>This release fixes a soundness issue in the broadcast channel. The
channel
accepts values that are <code>Send</code> but <code>!Sync</code>.
Previously, the channel called
<code>clone()</code> on these values without synchronizing. This release
fixes the channel
by synchronizing calls to <code>.clone()</code> (Thanks Austin Bonander
for finding and
reporting the issue).</p>
<h3>Fixed</h3>
<ul>
<li>sync: synchronize <code>clone()</code> call in broadcast channel (<a
href="https://redirect.github.com/tokio-rs/tokio/issues/7232">#7232</a>)</li>
</ul>
<p><a
href="https://redirect.github.com/tokio-rs/tokio/issues/7232">#7232</a>:
<a
href="https://redirect.github.com/tokio-rs/tokio/pull/7232">tokio-rs/tokio#7232</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="ec4b1d7215"><code>ec4b1d7</code></a>
chore: forward port 1.43.x</li>
<li><a
href="e3c3a56718"><code>e3c3a56</code></a>
Merge branch 'tokio-1.43.x' into forward-port-1.43.x</li>
<li><a
href="a7b658c35b"><code>a7b658c</code></a>
chore: prepare Tokio v1.43.1 release</li>
<li><a
href="c1c8d1033d"><code>c1c8d10</code></a>
Merge remote-tracking branch 'origin/tokio-1.38.x' into
forward-port-1.38.x</li>
<li><a
href="aa303bc205"><code>aa303bc</code></a>
chore: prepare Tokio v1.38.2 release</li>
<li><a
href="7b6ccb515f"><code>7b6ccb5</code></a>
chore: backport CI fixes</li>
<li><a
href="4b174ce2c9"><code>4b174ce</code></a>
sync: fix cloning value when receiving from broadcast channel</li>
<li>See full diff in <a
href="https://github.com/tokio-rs/tokio/compare/tokio-1.44.1...tokio-1.44.2">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)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/nushell/nushell/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [indexmap](https://github.com/indexmap-rs/indexmap) from 2.8.0 to
2.9.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/indexmap-rs/indexmap/blob/main/RELEASES.md">indexmap's
changelog</a>.</em></p>
<blockquote>
<h2>2.9.0 (2025-04-04)</h2>
<ul>
<li>Added a <code>get_disjoint_mut</code> method to
<code>IndexMap</code>, matching Rust 1.86's
<code>HashMap</code> method.</li>
<li>Added a <code>get_disjoint_indices_mut</code> method to
<code>IndexMap</code> and <code>map::Slice</code>,
matching Rust 1.86's <code>get_disjoint_mut</code> method on
slices.</li>
<li>Deprecated the <code>borsh</code> feature in favor of their own
<code>indexmap</code> feature,
solving a cyclic dependency that occured via
<code>borsh-derive</code>.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="1818d4140d"><code>1818d41</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/387">#387</a>
from cuviper/release-2.9.0</li>
<li><a
href="9f4998341b"><code>9f49983</code></a>
Release 2.9.0</li>
<li><a
href="582a90fda3"><code>582a90f</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/386">#386</a>
from cuviper/de-borsh</li>
<li><a
href="90117397b6"><code>9011739</code></a>
Deprecate the "borsh" feature</li>
<li><a
href="0a836e8648"><code>0a836e8</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/238">#238</a>
from NiklasJonsson/get_many_mut</li>
<li><a
href="434d7ac6d1"><code>434d7ac</code></a>
Avoid let-else for MSRV's sake</li>
<li><a
href="5be552d557"><code>5be552d</code></a>
Implement additional suggestions from review</li>
<li><a
href="4e1d8cef47"><code>4e1d8ce</code></a>
Address review feedback</li>
<li><a
href="5aec9ec674"><code>5aec9ec</code></a>
Implement get_disjoint_mut for arrays of keys</li>
<li><a
href="d10de30e74"><code>d10de30</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/385">#385</a>
from iajoiner/docs/macros</li>
<li>Additional commits viewable in <a
href="https://github.com/indexmap-rs/indexmap/compare/2.8.0...2.9.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>
I think after that we can close #14790
# Description
So the issue was the tiny time delta between the moment the "date
form-human" command is executed, and the moment the value gets
displayed, using chrono_humanize.
When in inputing "in 30 seconds", we currently get:
```
[crates\nu-protocol\src\value\mod.rs:950:21] HumanTime::from(*val) = HumanTime(
TimeDelta {
secs: 29,
nanos: 992402700,
},
)```
And with "now":
```
crates\nu-protocol\src\value\mod.rs:950:21] HumanTime::from(*val) =
HumanTime(
TimeDelta {
secs: -1,
nanos: 993393200,
},
)
```
My solution is to round this timedelta to seconds and pass this to chrono_humanize.
Example: instead of passing (-1s + 993393200ns), we pass 0s.
Example: instead of passing (29s + 992402700ns), we pass 30s
# User-Facing Changes
Before 🔴
```nushell
~> "in 3 days" | date from-human
Fri, 11 Apr 2025 09:06:36 +0200 (in 2 days)
~> "in 30 seconds" | date from-human
Tue, 8 Apr 2025 09:07:09 +0200 (in 29 seconds)
```
After those changes 🟢
```nushell
~> "in 3 days" | date from-human
Fri, 11 Apr 2025 09:03:47 +0200 (in 3 days)
~> "in 30 seconds" | date from-human
Tue, 8 Apr 2025 09:04:28 +0200 (in 30 seconds)
```
# 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
Now, with PWD correctly set in #15470 , identifiers in
`use/hide/overlay` commands can be identified using a more robust
method, i.e. module_id from `parser_info`.
# User-Facing Changes
bug fix
# Tests + Formatting
+1 (fails without this PR)
# After Submitting
# Description
The current implementation of `polars into-df` and `polars into-lazy`
will throw an error if `--schema` is provided but not all columns are
defined. This PR seeks to remove this requirement so that when a partial
`--schema` is provided, the types on the defined columns are overridden
while the remaining columns take on their default types.
**Current Implementation**
```
$ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df -s {a: str} | polars schema
Error: × Schema does not contain column: b
╭─[entry #88:1:12]
1 │ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df -s {a: str} | polars schema
· ─────
╰────
```
**New Implementation (no error thrown on partial schema definition)**
Column b is not defined in `--schema`
```
$ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df --schema {a: str} | polars schema
╭───┬─────╮
│ a │ str │
│ b │ str │
╰───┴─────╯
```
# User-Facing Changes
Soft breaking change: The user's previous (erroneous) code that would
have thrown an error would no longer throw an error. The user's previous
working code will still work.
# Tests + Formatting
# After Submitting
No related issue.
Decided in nushell's weekly meeting: see [meeting
notes](https://hackmd.io/rA1YecqjRh6I5m8dTq7BHw)
# Description
Converting a date as a human readable string to a datetime:
- currently: using the ``into datetime`` command
- after this change: using ``date from-human`` command
Also moved the ``--list-human`` flag to the new command.
# User-Facing Changes
- Users have to use a new command for parsing human readable datetimes.
Result:
```nushell
~> date from-human --list
╭────┬───────────────────────────────────┬──────────────╮
│ # │ parseable human datetime examples │ result │
├────┼───────────────────────────────────┼──────────────┤
│ 0 │ Today 18:30 │ in 6 hours │
│ 1 │ 2022-11-07 13:25:30 │ 2 years ago │
│ 2 │ 15:20 Friday │ in 6 days │
│ 3 │ This Friday 17:00 │ in 6 days │
│ 4 │ 13:25, Next Tuesday │ in 3 days │
│ 5 │ Last Friday at 19:45 │ 16 hours ago │
│ 6 │ In 3 days │ in 2 days │
│ 7 │ In 2 hours │ in 2 hours │
│ 8 │ 10 hours and 5 minutes ago │ 10 hours ago │
│ 9 │ 1 years ago │ a year ago │
│ 10 │ A year ago │ a year ago │
│ 11 │ A month ago │ a month ago │
│ 12 │ A week ago │ a week ago │
│ 13 │ A day ago │ a day ago │
│ 14 │ An hour ago │ an hour ago │
│ 15 │ A minute ago │ a minute ago │
│ 16 │ A second ago │ now │
│ 17 │ Now │ now │
╰────┴───────────────────────────────────┴──────────────╯
~> "2 days ago" | date from-human
Thu, 3 Apr 2025 12:03:33 +0200 (2 days ago)
~> "2 days ago" | into datetime
Error: nu:🐚:datetime_parse_error
× Unable to parse datetime: [2 days ago].
╭─[entry #5:1:1]
1 │ "2 days ago" | into datetime
· ──────┬─────
· ╰── datetime parsing failed
╰────
help: Examples of supported inputs:
* "5 pm"
* "2020/12/4"
* "2020.12.04 22:10 +2"
* "2020-04-12 22:10:57 +02:00"
* "2020-04-12T22:10:57.213231+02:00"
* "Tue, 1 Jul 2003 10:52:37 +0200"
```
# Tests + Formatting
Fmt, clippy 🆗
Tests 🆗
> Note: I was able to reactivate one unit test in the ``into datetime``
command
# After Submitting
Here since the user facing changes are significant, I think we should
communicate in the released notes. Otherwise the automatically generated
documentation should be enough IMO.
Closes#15502
# Description
The parsing of Exbibytes used the wrong base unit before converting.
# User-Facing Changes
`1EiB` etc. will now be parsed correctly
# Tests + Formatting
(-)
sub-issue of #10698 according to @sholderbach
(Description largely edited, since the scope of the PR changed)
# Description
Context: `ShellError::OnlySupportsThisInputType` was a duplicate of
`ShellError::PipelineMismatch`
so I
- replaced some occurences of PipelineMismatch by
OnlySupportsThisInputType
For another PR
- replace the remaining occurences
- removed OnlySupportsThisInputType from nu-protocol
# User-Facing Changes
The error message will be different -> but consistent
# Tests + Formatting
OK
# After Submitting
Nothing required
#15499 reminds me of the discrepancies between lsp hover docs and
`--help` outputs.
# Description
# User-Facing Changes
Before:
<img width="610" alt="image"
src="https://github.com/user-attachments/assets/f73f7ace-5c1b-4380-9921-fb4783bdb187"
/>
After:
<img width="610" alt="image"
src="https://github.com/user-attachments/assets/96de3ffe-e37b-41b1-88bb-123eeb72ced2"
/>
Output of `if -h` as a reference:
```
Usage:
> if <cond> <then_block> (else <else_expression>)
Flags:
-h, --help: Display the help message for this command
Parameters:
cond <variable>: Condition to check.
then_block <block>: Block to run if check succeeds.
"else" + <one_of(block, expression)>: Expression or block to run when the condition is false. (optional)
```
# Tests + Formatting
Refined
# After Submitting
# Description
There are some clippy(version 0.1.86) errors on nushell repo. This pr is
trying to fix it.
# User-Facing Changes
Hopefully none.
# Tests + Formatting
NaN
# After Submitting
NaN
Fixes#15503
# Description
Our usage of `serde_json::Error::io_error_kind` is improperly handled in
the workspace version specifier.
We use this method in `nu-plugin-core`
f25525be6c/crates/nu-plugin-core/src/serializers/json.rs (L77-L106)
It was added in [`serde_json`
v1.0.97](https://github.com/serde-rs/json/releases/tag/v1.0.97).
Previously, we specified our version requirement only as `1.0`. Now, it
is `>=1.0.97,<1.1`, which correctly describes our maximum range of
compatibility.
# User-Facing Changes
None
# Tests + Formatting
No code has changed. Recent releases are identical. This only effect
usage of nushell as a library
# After Submitting
No doc changes should be needed. This prevents certain compiler errors,
but will not change the behavior of any compiled project.
# Description
Some editors like neovim will provide "workspace root" as PWD, which can
mess up file completion results.
# User-Facing Changes
bug fix
# Tests + Formatting
adjusted
# After Submitting
# Description
This PR seeks to fix an error in `polars as-datetime` where timezone
information is entirely ignored. This behavior raises a host of silent
errors when dealing with datetime conversions (see example below).
## Current Implementation
Timezones are entirely ignored and datetimes with different timezones
are converted to the same naive datetimes even when the user
specifically indicates that the timezone should be parsed. For example,
"2021-12-30 00:00:00 +0000" and "2021-12-30 00:00:00 -0400" will both be
parsed to "2021-12-30 00:00:00" even when the format string specifically
includes "%z".
```
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z"
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 12/30/2021 12:00:00AM │
│ 1 │ 12/30/2021 12:00:00AM │ <-- Same datetime even though the first is +0000 and second is -0400
╰───┴───────────────────────╯
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z" | polars schema
╭──────────┬──────────────╮
│ datetime │ datetime<ns> │
╰──────────┴──────────────╯
```
## New Implementation
Datetimes are converted to UTC and timezone information is retained.
```
$ "2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z"
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 12/30/2021 12:00:00AM │
│ 1 │ 12/30/2021 04:00:00AM │ <-- Converted to UTC
╰───┴───────────────────────╯
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z" | polars schema
╭──────────┬───────────────────╮
│ datetime │ datetime<ns, UTC> │
╰──────────┴───────────────────╯
```
The user may intentionally ignore timezone information by setting the
`--naive` flag.
```
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z" --naive
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 12/30/2021 12:00:00AM │
│ 1 │ 12/30/2021 12:00:00AM │ <-- the -0400 offset is ignored when --naive is set
╰───┴───────────────────────╯
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z" --naive | polars schema
╭──────────┬──────────────╮
│ datetime │ datetime<ns> │
╰──────────┴──────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
`polars as-datetime` will now account for timezone information and
return type `datetime<ns,UTC>` rather than `datetime<ns>` by default.
The user can replicate the previous behavior by setting `--naive`.
# 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
> ```
-->
Tests that incorporated `polars as-datetime` had to be tweaked to
include `--naive` flag to replicate previous behavior.
# 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!
-->
Fixes#15476
# 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.
-->
Consider PATH when checking for potential_nuscript_in_windows to allow
executing scripts which are in PATH without having to full path address
them. It previously only checked the current working directory so only
relative paths to cwd and full path worked.
The current implementation runs this then through cmd.exe /D /C which
can run it with assoc and ftype set for nushell scripts.
We could instead run it through nu as `std::env::current_exe()` avoiding
the cmd call and the need for assoc and ftype (see:
8b25173f02).
But ive left the current implementation for this intact to not change
implementation details, avoid a bigger change and leave this open for
discussion here since im not sure if this has any major implications.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
This would now run every external command through PATH an additional
time on windows, so potentially twice. I dont think this has any bigger
effect.
# 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
Noticed there is a build failure in #15420, because `ShadowBuilder`
struct is guarded by `build` feature. This pr is going to update it.
# User-Facing Changes
Hopefully none.
# Tests + Formatting
None
# After Submitting
None
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
Issue #9887 which can be closed after this is merged.
# Description
This allows the "into duration" command to accept floats as inputs.
Examples:
<img width="767" alt="image"
src="https://github.com/user-attachments/assets/da181f2a-7ad6-4efb-a6db-f9c6d8929c71"
/>
<img width="710" alt="image"
src="https://github.com/user-attachments/assets/78623a39-33ad-42a0-9324-a147be86f95c"
/>
**How it works:**
Using strings, like `"1.234sec" | into duration`, is already working, so
if a user inputs `1.234 | into duration --sec`, I just convert this back
to a string and use the previous conversion functions.
**Limitations:**
there are some limitation to using floats, but it's a general limitation
that is already present for other use cases:
- only 3 digits are taken into account in the decimal part
- floating durations in nano seconds are always floored and not rounded
<img width="761" alt="image"
src="https://github.com/user-attachments/assets/a9076aab-da03-43f2-927c-c9703fc4f955"
/>
# User-Facing Changes
Users can inject floats with `into duration`
# Tests + Formatting
cargo fmt and clippy OK
Tests OK
# After Submitting
The example I added will automatically become part of the doc, I think
that's enough for documentation.
This should be a more robust method.
# Description
Previously, `export use` with double-space in between will fail to be
recognized as command `export use`.
# User-Facing Changes
minor bug fix
# Tests + Formatting
test cases made harder
# After Submitting
Bumps [bytesize](https://github.com/bytesize-rs/bytesize) from 1.3.2 to
1.3.3.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="603a713824"><code>603a713</code></a>
chore: prepare release v1.3.3</li>
<li>See full diff in <a
href="https://github.com/bytesize-rs/bytesize/compare/v1.3.2...v1.3.3">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
This PR expands the `dtype` parameter of the `polars cast` command to
include `decimal<precision, scale>` type. Setting precision to "*" will
compel inferring the value. Note, however, setting scale to a
non-integer value will throw an explicit error (the underlying polars
crate assigns scale = 0 in such a case, but I opted for throwing an
error instead). .
```
$ [[a b]; [1 2] [3 4]] | polars into-df | polars cast decimal<4,2> a | polars schema
╭───┬──────────────╮
│ a │ decimal<4,2> │
│ b │ i64 │
╰───┴──────────────╯
$ [[a b]; [10.5 2] [3.1 4]] | polars into-df | polars cast decimal<*,2> a | polars schema
╭───┬──────────────╮
│ a │ decimal<*,2> │
│ b │ i64 │
╰───┴──────────────╯
$ [[a b]; [10.05 2] [3.1 4]] | polars into-df | polars cast decimal<5,*> a | polars schema
rror: × Invalid polars data type
╭─[entry #25:1:47]
1 │ [[a b]; [10.05 2] [3.1 4]] | polars into-df | polars cast decimal<5,*> a | polars schema
· ─────┬─────
· ╰── `*` is not a permitted value for scale
╰────
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
There are no breaking changes. The user has the additional option to
`polars cast` to a decimal type
# Tests + Formatting
Tests have been added to
`nu_plugin_polars/src/dataframe/values/nu_schema.rs`
# Description
There's been much debate about whether to keep human-date-parser in
`into datetime`. We saw recently that a new version of the crate was
released that addressed some of our concerns. This PR is to make it
easier to test those fixes.
# 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.
-->
Follow-up to #15277 and #15392.
Adds examples to `any` and `all` demonstrating using `any {}` or `all
{}` with lists of booleans.
We have a couple options that work for this use-case, but not sure which
we should recommend. The PR currently uses (1).
1. `any {}` / `all {}`
2. `any { $in }` / `all { $in }`
3. `any { $in == true }` / `all { $in == true }`
Would love to hear your thoughts on the above @fennewald @mtimaN
@fdncred @NotTheDr01ds @ysthakur
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Added an extra example for `any` and `all`
# 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
# Description
As description, I think it's worth to move forward to update rand and
rand_chacha to 0.9.
# User-Facing Changes
Hopefully none
# Tests + Formatting
NaN
# After Submitting
NaN
Bumps [array-init-cursor](https://github.com/planus-org/planus) from
0.2.0 to 0.2.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/planus-org/planus/blob/main/CHANGELOG.md">array-init-cursor's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>The format is based on <a
href="https://keepachangelog.com/en/1.0.0/">Keep a Changelog</a>,
and this project adheres to <a
href="https://semver.org/spec/v2.0.0.html">Semantic Versioning</a>.</p>
<h2>[Unreleased]</h2>
<h3>Added</h3>
<h3>Fixed</h3>
<h3>Removed</h3>
<h2>[1.1.1] - 2025-03-02</h2>
<h3>Added</h3>
<h3>Fixed</h3>
<ul>
<li>[Rust]: Fix the alignment of structs in unions <a
href="https://redirect.github.com/planus-org/planus/pull/289">#289</a></li>
</ul>
<h3>Removed</h3>
<h2>[1.1.0] - 2025-03-02</h2>
<h3>Added</h3>
<ul>
<li>Bump the Minimum Support Rust Version (MSRV) to 1.75.0</li>
<li>The <code>Primitive</code> and <code>VectorWrite</code> traits are
now marked as unsafe to remind implementers of alignment
constraints</li>
<li>[Rust]: Add support for union vectors <a
href="https://redirect.github.com/planus-org/planus/pull/287">#287</a></li>
<li>Add support for displaying union vectors with <code>planus
view</code> <a
href="https://redirect.github.com/planus-org/planus/pull/287">#287</a></li>
</ul>
<h3>Fixed</h3>
<ul>
<li>Added extra unsafe blocks to templates to fix warnings for the 2024
edition</li>
<li>Updated tests for the 2024 edition</li>
</ul>
<h3>Removed</h3>
<h2>[1.0.0] - 2024-09-29</h2>
<h3>Added</h3>
<ul>
<li>[Rust]: Added <code>#[allow(dead_code)]</code> to the root of the
generated rust code <a
href="https://redirect.github.com/planus-org/planus/pull/204">#204</a></li>
<li>Added the option <code>ignore_docstring_errors</code> to the app. <a
href="https://redirect.github.com/planus-org/planus/pull/216">#216</a></li>
<li>Get rid of dependency on <code>atty</code> and bump the Minimum
Support Rust Version (MSRV) to 1.70.0. <a
href="https://redirect.github.com/planus-org/planus/pull/220">#220</a></li>
<li>[Rust]: Allow default implementations to be generated for tables
that have fields with (required) vectors, strings, integers and bools.
<a
href="https://redirect.github.com/planus-org/planus/pull/243">#243</a></li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="be6f99afde"><code>be6f99a</code></a>
Add a soundness fix for array-init-cursor (<a
href="https://redirect.github.com/planus-org/planus/issues/294">#294</a>)</li>
<li><a
href="1cf18d16af"><code>1cf18d1</code></a>
Release 1.1.1 (<a
href="https://redirect.github.com/planus-org/planus/issues/290">#290</a>)</li>
<li><a
href="e1928da42c"><code>e1928da</code></a>
Fix alignment of large structs in unions (<a
href="https://redirect.github.com/planus-org/planus/issues/289">#289</a>)</li>
<li><a
href="060ffc788a"><code>060ffc7</code></a>
Release version 1.1.0 (<a
href="https://redirect.github.com/planus-org/planus/issues/288">#288</a>)</li>
<li><a
href="d96b907d3f"><code>d96b907</code></a>
Implement union vectors (<a
href="https://redirect.github.com/planus-org/planus/issues/287">#287</a>)</li>
<li><a
href="08d8c012a5"><code>08d8c01</code></a>
Small fixes (<a
href="https://redirect.github.com/planus-org/planus/issues/286">#286</a>)</li>
<li><a
href="b8129d7691"><code>b8129d7</code></a>
Mark <code>Primitive</code> and <code>VectorWrite</code> as unsafe (<a
href="https://redirect.github.com/planus-org/planus/issues/280">#280</a>)</li>
<li><a
href="b5d9d8194a"><code>b5d9d81</code></a>
Update the test suite (<a
href="https://redirect.github.com/planus-org/planus/issues/283">#283</a>)</li>
<li><a
href="4f04f66577"><code>4f04f66</code></a>
Add extra unsafe blocks as required by 2024 edition (<a
href="https://redirect.github.com/planus-org/planus/issues/282">#282</a>)</li>
<li><a
href="44ffb38190"><code>44ffb38</code></a>
New rust version, new clippy issues to fix</li>
<li>Additional commits viewable in <a
href="https://github.com/planus-org/planus/compare/v0.2.0...array-init-cursor-v0.2.1">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)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/nushell/nushell/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Description
```
# table.*
# table_mode (string):
# One of: "default", "basic", "compact", "compact_double", "heavy", "light", "none", "reinforced",
# "rounded", "thin", "with_love", "psql", "markdown", "dots", "restructured", "ascii_rounded",
# or "basic_compact"
# Can be overridden by passing a table to `| table --theme/-t`
$env.config.table.mode = "default"
```
In `doc_config.nu`, it refers to `table_mode` which does not exist under
`$env.config.table`. There is now a short description of this field as
well.
# Description
Closes#14794. This PR enables the strict exact match behavior requested
in #13204 and #14794 for any path containing a slash (#13302 implemented
this for paths ending in slashes).
If any of the components along the way *don't* exactly match a
directory, then the next components will use the old Fish-like
completion behavior rather than the strict behavior.
This change only affects those using prefix matching. Fuzzy matching
remains unaffected.
# User-Facing Changes
Suppose you have the following directory structure:
```
- foo
- bar
- xyzzy
- barbaz
- xyzzy
- foobar
- bar
- xyzzy
- barbaz
- xyzzy
```
- If you type `cd foo<TAB>`, you will be suggested `[foo, foobar]`
- This is because `foo` is the last component of the path, so the strict
behavior isn't activated
- Similarly, `foo/bar` will show you `[foo/bar, foo/barbaz]`
- If you type `foo/bar/x`, you will be suggested `[foo/bar/xyzzy]`
- This is because `foo` and `bar` both exactly matched a directory
- If you type `foo/b/x`, you will be suggested `[foo/bar/xyzzy,
foo/barbaz/xyzzy]`
- This is because `foo` matches a directory exactly, so `foobar/*` won't
be suggested, but `b` doesn't exactly match a directory, so both `bar`
and `barbaz` are suggested
- If you type `f/b/x`, you will be suggested all four of the `xyzzy`
files above
- If you type `f/bar/x`, you will be suggested all four of the `xyzzy`
files above
- Since `f` doesn't exactly match a directory, every component after it
won't use the strict matching behavior (even though `bar` exactly
matches a directory)
# Tests + Formatting
# After Submitting
This is a pretty minor change but should be mentioned somewhere in the
release notes in case it surprises someone.
---------
Co-authored-by: 132ikl <132@ikl.sh>
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
Fixes#14794.
# 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
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Makes it so that (even if) the command ends in a slash, exact matches
are still preferred over partial matches.
For example, `foo/bar/as` -> `foo/bar/asdf` but not `foo/bars/asdf`.
# 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: Yash Thakur <45539777+ysthakur@users.noreply.github.com>
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.29.10
to 1.30.3.
<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.30.3</h2>
<h2>[1.30.3] - 2025-03-24</h2>
<h3>Features</h3>
<ul>
<li>Support detecting <code>go.work</code> and <code>go.work.sum</code>
files</li>
</ul>
<h2>v1.30.2</h2>
<h2>[1.30.2] - 2025-03-10</h2>
<h3>Features</h3>
<ul>
<li>Add <code>--highlight-words</code> and
<code>--highlight-identifiers</code> for easier debugging of config</li>
</ul>
<h2>v1.30.1</h2>
<h2>[1.30.1] - 2025-03-04</h2>
<h3>Features</h3>
<ul>
<li><em>(action)</em> Create <code>v1</code> tag</li>
</ul>
<h2>v1.30.0</h2>
<h2>[1.30.0] - 2025-03-01</h2>
<h3>Features</h3>
<ul>
<li>Updated the dictionary with the <a
href="https://redirect.github.com/crate-ci/typos/issues/1221">February
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.30.3] - 2025-03-24</h2>
<h3>Features</h3>
<ul>
<li>Support detecting <code>go.work</code> and <code>go.work.sum</code>
files</li>
</ul>
<h2>[1.30.2] - 2025-03-10</h2>
<h3>Features</h3>
<ul>
<li>Add <code>--highlight-words</code> and
<code>--highlight-identifiers</code> for easier debugging of config</li>
</ul>
<h2>[1.30.1] - 2025-03-04</h2>
<h3>Features</h3>
<ul>
<li><em>(action)</em> Create <code>v1</code> tag</li>
</ul>
<h2>[1.30.0] - 2025-03-01</h2>
<h3>Features</h3>
<ul>
<li>Updated the dictionary with the <a
href="https://redirect.github.com/crate-ci/typos/issues/1221">February
2025</a> changes</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="d08e4083f1"><code>d08e408</code></a>
chore: Release</li>
<li><a
href="6f7dfef019"><code>6f7dfef</code></a>
docs: Update changelog</li>
<li><a
href="e601194a5d"><code>e601194</code></a>
Merge pull request <a
href="https://redirect.github.com/crate-ci/typos/issues/1261">#1261</a>
from epage/go</li>
<li><a
href="9a82085508"><code>9a82085</code></a>
fix(type): Include support for go.work</li>
<li><a
href="8c7c9e5c7c"><code>8c7c9e5</code></a>
Merge pull request <a
href="https://redirect.github.com/crate-ci/typos/issues/1259">#1259</a>
from j-g00da/patch-1</li>
<li><a
href="62bb5ad3c6"><code>62bb5ad</code></a>
docs: fix a typo in README.md</li>
<li><a
href="b48ba0f02b"><code>b48ba0f</code></a>
docs(gh): Mention v1 tag</li>
<li><a
href="7bc041cbb7"><code>7bc041c</code></a>
chore: Release</li>
<li><a
href="4af8a5a1fb"><code>4af8a5a</code></a>
docs: Update changelog</li>
<li><a
href="ec626a1e53"><code>ec626a1</code></a>
Merge pull request <a
href="https://redirect.github.com/crate-ci/typos/issues/1257">#1257</a>
from epage/highlight</li>
<li>Additional commits viewable in <a
href="https://github.com/crate-ci/typos/compare/v1.29.10...v1.30.3">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.
-->
Fix upgrading and checking of typos
# Description
Add parse warnings to LSP diagnostics, not particularly useful but
technically should be done.
# User-Facing Changes
# Tests + Formatting
There's no deprecated command to test for now.
# After Submitting
Fixes#15414 by changing the method used to de-ansi-fy the input. Control characters will now be kept when using `clip copy`, but ANSI escape codes will be removed (when not using `--ansi (-a)`)
Fixes#15441
# Description
Actually I made a small change to the original behavior:
```
^foo<tab>
```
will still show external commands, regardless of whether it's enabled or
not. I think that's the only thing people want to see when they press
tab with a `^` prefix.
# User-Facing Changes
# Tests + Formatting
+1
# After Submitting
Should I document that minor behavior change somewhere in GitHub.io?
---------
Co-authored-by: Yash Thakur <45539777+ysthakur@users.noreply.github.com>
Close#15119 when this is merged
# Description
> Note: my locale is +1
**Before the changes 🔴**
See the issue for more detailed description of the problem.
**After the changes 🟢**
# User-Facing Changes
The ``into datetime`` command will now work with formatting and time
zones or offset together
# Tests + Formatting
Fmt + clippy OK
**Note about the tests I added**: those tests don't really test my
changes, as they were already passing before my changes. Nevertheless I
thought I could push them
# After Submitting
I don't think anything is necessary
The `$env.SHLVL` tests, while improved, still cause CI (usually local)
an irritating percentage of the time. Until we can come with a better
way of testing, we're going to ignore them.
No linked issue, it's a follow-up of 2 PRs I recently made to improve
some math commands. (#15319)
# Description
Small refactor to simplify the code. It was suggested in the comments of
my previous PR.
# User-Facing Changes
None
# Tests + Formatting
Tests, fmt and clippy OK
# After Submitting
Nothing more required
fixes#8095
# Description
This approach is a bit straightforward, call access() check with the
flag `X_OK`.
Zsh[^1], Fish perform this check by the same approach.
[^1]:
435cb1b748/Src/exec.c (L6406)
It could also avoid manual xattrs check on other *nix platforms.
BTW, the execution bit for directories in *nix world means permission to
access it's content,
while the read bit means to list it's content. [^0]
[^0]: https://superuser.com/a/169418
# User-Facing Changes
Users could face less permission check bugs in their `cd` usage.
# 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: Stefan Holderbach <sholderbach@users.noreply.github.com>
Closes#15395
# User-Facing Changes
Certain errors no longer leave the argument stack in an unexpected
state:
```diff
let x: any = 1; try { $x | get path } catch { print caught }
-$.path # extra `print` argument from the failed `get` call
caught
```
# Description
If `eval_call` fails in `check_input_types` or `gather_arguments`, the
cleanup code is still executed.
Fixes#14972#15321#14706
# Description
Early returns `NotAConstant` if parsing errors exist in the
subexpression.
I'm not sure when the span of a block will be None, and whether there're
better ways to handle none block spans, like a more suitable ShellError
type.
# User-Facing Changes
# Tests + Formatting
+1, but possibly not the easiest way to do it.
# After Submitting
Closes#15305
# Description
Basically turns off `skip_comments` of the lex function for right hand
side expressions of `let`/`mut`, just as in `parse_const`.
# User-Facing Changes
Should be none.
# Tests + Formatting
+1
# After Submitting
Quality-of-life improvement - Since core plugins are installed into the
same directory as the Nushell binary, this simply adds that directory to
the default `$NU_PLUGIN_DIRS`.
User-facing changes:
The default directory for core plugins is automatically added to the
`$NU.PLUGIN_DIRS` with no user action necessary. Uses can immediately,
out-of-the-box:
```nushell
plugin add nu_plugin_polars
plugin use polars
```
`path add`, when given a record, sets `$env.PATH` according to the value
of the key matching `$nu.os-info.name`. There already existed a check in
place to ensure the correct column existed, but it was never reached
because of an early error on `path expand`ing `null`. This has been
fixed, as well as the out-of-date reference to "darwin" instead of
"macos" in the example.
# User-Facing Changes
`path add` now simply ignores a record that doesn't include a key for the current OS
`path add` also will no longer add duplicate paths.
We only have one valid `datetime` type, but the string representation of
that type was `date`. This PR updates the string representation of the
`datetime` type to be `datetime` and updates other affected
dependencies:
* A `describe` example that used `date`
* The style computer automatically recognized the new change, but also
changed the default `date: purple` to `datetime: purple`.
* Likewise, changed the `default_config.nu` to populate
`$env.config.color_config.datetime`
* Likewise, the dark and light themes in `std/config`
* Updates tests
* Unrelated, but changed the `into value` error messages to use
*"datetime"* if there's an issue.
Fixes#9916 and perhaps others.
## Breaking Changes:
* Code that expected `describe` to return a `date` will now return a
`datetime`
* User configs and themes that override `$env.config.color_config.date`
will need to be updated to use `datetime`
Closes#15373
# Description
Now `ast -f "{||}"` will return
```
╭─content─┬─────shape─────┬─────span──────╮
│ {||} │ shape_closure │ ╭───────┬───╮ │
│ │ │ │ start │ 0 │ │
│ │ │ │ end │ 4 │ │
│ │ │ ╰───────┴───╯ │
╰─────────┴───────────────┴───────────────╯
```
Similar to those of `ast -f "[]"`/`ast -f "{}"`
# User-Facing Changes
# Tests + Formatting
I didn't find the right place to do the test, except for the examples of
`ast` command.
# After Submitting
# Description
Closes#15351
Adds quotes that were missed in #14698 with the proper escaping.
# User-Facing Changes
`to nuon --serialize` will now produce a quoted string instead of
illegal nuon when given a closure
# Tests + Formatting
Reenable the `to nuon` rejection of closures in the base state test.
Added test for quoting.
# Description
This PR solves a circular dependency issue (`nu-test-support` needs
`nu-glob` which needs `nu-protocol` which needs `nu-test-support`). This
was done by making the glob functions that any type that implements
`Interruptible` to remove the dependency on `Signals`.
# After Submitting
Make `Paths.next()` a O(1) operation so that cancellation/interrupt
handling can be moved to the caller (e.g., by wrapping the `Paths`
iterator in a cancellation iterator).
<!--
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 an `impl From<IoError> for LabeledError`, similar to the existing
`From<ShellError>` implementation. Helpful for plugins.
# 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
# Description
Some editors (like zed) will fail to mark the active parameter if not
set in the outmost structure.
# User-Facing Changes
# Tests + Formatting
Adjusted
# After Submitting
# Description
This PR adds a few more columns to the macos version of `ps -l` to bring
it more inline with the Linux and Windows version.
Columns added: user_id, priority, process_threads
I also added some comments that describe the TaskInfo structure. I
couldn't find any good information to add to the BSDInfo structure.
# 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
Bump the uutils crates to 0.0.30. This bump changed a lot of deps in the
lock file. I'm not sure if we should wait a bit on this or just go for
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.
-->
@ -31,7 +31,7 @@ The review process can be summarized as follows:
1. You want to make some change to Nushell that is more involved than simple bug-fixing.
2. Go to [Discord](https://discordapp.com/invite/NtAbbGn) or a [GitHub issue](https://github.com/nushell/nushell/issues/new/choose) and chat with some core team members and/or other contributors about it.
3. After getting a green light from the core team, implement the feature, open a pull request (PR) and write a concise but comprehensive description of the change.
4. If your PR includes any use-facing features (such as adding a flag to a command), clearly list them in the PR description.
4. If your PR includes any user-facing features (such as adding a flag to a command), clearly list them in the PR description.
5. Then, core team members and other regular contributors will review the PR and suggest changes.
6. When we all agree, the PR will be merged.
7. If your PR includes any user-facing features, make sure the changes are also reflected in [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged.
If no input is provided, will import all history items from existing history in the other format: if current history is stored in sqlite, it will store it in plain text and vice versa.
@ -48,8 +48,7 @@ Note that history item IDs are ignored when importing from file."#
vec