# 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
<!--
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
# 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>
# 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
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
`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
The `job unfreeze` command relies on the `os` feature of the
`nu-protocol` crate, which means that `nu-command` doesn't compile with
`--no-default-features`. This PR gates `job unfreeze` behind
`nu-command`'s `os` feature to avoid this.
No user-facing changes, no tests needed.
# Description
Follow-up to #15272, changing default to disallow DTD as discussed.
Especially applicable for the `http get` case.
# User-Facing Changes
Changes behavior introduced in #15272, so release notes need to be
updated to reflect this
Fixes messed ansi escapes in hover text (manpage):
<img width="392" alt="image"
src="https://github.com/user-attachments/assets/37c16520-d499-4079-93d9-0eccd1cfa8de"
/>
# Description
That bug is introduced in #15115.
Also refactored the hover related code to a separate file, just like
other features.
# User-Facing Changes
# Tests + Formatting
# After Submitting
