# 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.
-->
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>
# 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
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.
-->
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.
-->
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
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 😄
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.
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. -->
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.
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
# 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
<!--
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.
-->
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.
# 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
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
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.
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`
# 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).
# 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
The `job unfreeze` command relies on the `os` feature of the
`nu-protocol` crate, which means that `nu-command` doesn't compile with
`--no-default-features`. This PR gates `job unfreeze` behind
`nu-command`'s `os` feature to avoid this.
No user-facing changes, no tests needed.
# Description
Follow-up to #15272, changing default to disallow DTD as discussed.
Especially applicable for the `http get` case.
# User-Facing Changes
Changes behavior introduced in #15272, so release notes need to be
updated to reflect this
# Description
`into string` should not modify input strings (even with the
`--group-digits` flag). It's a conversion command, not a formatting
command.
# User-Facing Changes
- For strings, the same behavior from 0.102.0 is preserved.
- Errors are no longer turned into strings, but rather they are returned
as is.
# After Submitting
Create a `format int` and/or `format float` command and so that the
`--group-digits` flag can be transferred to one of those commands.
# Description
Before this PR, `to msgpack`/`to msgpackz` and `to json` serialize
closures as `nil`/`null` respectively, when the `--serialize` option
isn't passed. This PR makes it an error to serialize closures to msgpack
or JSON without the `--serialize` flag, which is the behavior of `to
nuon`.
This PR also adds the `--serialize` flag to `to msgpack`.
This PR also changes `to nuon` and `to json` to return an error if they
cannot find the block contents of a closure, rather than serializing an
empty string or an error string, respectively. This behavior is
replicated for `to msgpack`.
It also changes `to nuon`'s error message for serializing closures
without `--serialize` to be the same as the new errors for `to json` and
`to msgpack`.
# User-Facing Changes
* Add `--serialize` flag to `to msgpack`, similar to the `--serialize`
flag for `to nuon` and `to json`.
* Serializing closures to JSON or msgpack without `--serialize`
Partially fixes#11738
While inspecting the Windows specific code of `ls` for #15311 I stumbled
upon an unrelated issue in the alternate metadata gathering on Windows
(added by #5703).
The handle created by performing `FindFirstFileW` was never closed,
leading to a potential leak. Fixed by running `FindClose` as soon as the
operation succeeds.
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilew#remarks
Came from [this
discussion](https://discord.com/channels/601130461678272522/1348791953784836147/1349699872059691038)
on discord with @fdncred
# Description
Small refactoring where I rename commands from "SubCommand" to its
proper name. Motivations: better clarity (although subjective), better
searchable, consistency.
The only commands I didn't touch were "split list" and "ansi gradient"
because of name clashes.
# User-Facing Changes
None
# Tests + Formatting
cargo fmt and clippy OK
# After Submitting
nothing required
# Description
Adds a new `--empty/-e` flag to the `default` command.
# User-Facing Changes
Before:
```nushell
$env.FOO = ""
$env.FOO = $env.FOO? | default bar
$env.FOO
# => Empty string
```
After:
```nushell
$env.FOO = ""
$env.FOO = $env.FOO? | default -e bar
$env.FOO
# => bar
```
* Uses `val.is_empty`, which means that empty lists and records are also
replaced
* Empty values in tables (with a column specifier) are also replaced.
# Tests + Formatting
7 tests added and 1 updated + 1 new example
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
N/A
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR allows `from xml` to parse XML documents with [document type
declarations](https://en.wikipedia.org/wiki/Document_type_declaration)
by default. This is especially notable since many HTML documents start
with `<!DOCTYPE html>`, and `roxmltree` should be able to parse some
simple HTML documents. The security concerns with DTDs are [XXE
attacks](https://en.wikipedia.org/wiki/XML_external_entity_attack), and
[exponential entity expansion
attacks](https://en.wikipedia.org/wiki/Billion_laughs_attack).
`roxmltree` [doesn't
support](d2c7801624/src/tokenizer.rs (L535-L547))
external entities (it parses them, but doesn't do anything with them),
so it is not vulnerable to XXE attacks. Additionally, `roxmltree` has
[some
safeguards](d2c7801624/src/parse.rs (L424-L452))
in place to prevent exponential entity expansion, so enabling DTDs by
default is relatively safe. The worst case is no worse than running
`loop {}`, so I think allowing DTDs by default is best, and DTDs can
still be disabled with `--disallow-dtd` if needed.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Allows `from xml` to parse XML documents with [document type
declarations](https://en.wikipedia.org/wiki/Document_type_declaration)
by default, and adds a `--disallow-dtd` flag to disallow parsing
documents with DTDs.
This PR also improves the errors in `from xml` by pointing at the issue
in the XML source. Example:
```
$ open --raw foo.xml | from xml
Error: × Failed to parse XML
╭─[2:7]
1 │ <html>
2 │ <p<>hi</p>
· ▲
· ╰── Unexpected character <, expected a whitespace
3 │ </html>
╰────
```
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
N/A
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
N/A
Fix failing test by ignoring the local offset when converting times, but still displaying the
resulting date in the local timezone (including applicable DST offset).
# User-Facing Changes
Fix: Unix Epochs now convert consistently regardless of whether DST is
in effect in the local timezone or not.
### Description
Fixes issue #15135
Result
Also this works with other commands: min, max, sum, product, avg...
### User-Facing Changes
Error is returned, instead of console completely blocked and having to
be killed
I chose "Incorrect value", because commands accept inputs of range type,
just cannot work with unbounded ranges.
### Tests + Formatting
- ran cargo fmt, clippy
- added tests
# Description
Commands and other pieces of code using `$env.config.format.filesize` to
format filesizes now respect the system locale when formatting the
numeric portion of a file size.
# User-Facing Changes
- System locale is respected when using `$env.config.format.filesize` to
format file sizes.
- Formatting a file size with a binary unit is now exact for large file
sizes and units.
- The output of `to text` is no longer dependent on the config.
# Description
This PR allows the `into string` command to pass the `--group-digits`
flag which already existed in this code but was hard coded to `false`.
Now you can do things like
```nushell
❯ 1234567890 | into string --group-digits
1,234,567,890
❯ ls | into string size --group-digits | last 5
╭─#─┬────────name─────────┬─type─┬──size──┬───modified───╮
│ 0 │ README.md │ file │ 12,606 │ 4 weeks ago │
│ 1 │ rust-toolchain.toml │ file │ 1,125 │ 2 weeks ago │
│ 2 │ SECURITY.md │ file │ 2,712 │ 7 months ago │
│ 3 │ toolkit.nu │ file │ 21,929 │ 2 months ago │
│ 4 │ typos.toml │ file │ 542 │ 7 months ago │
╰─#─┴────────name─────────┴─type─┴──size──┴───modified───╯
❯ "12345" | into string --group-digits
12,345
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
