When looking into `lite_parse` function, I found that it contains some
duplicate code, and they can be expressed as an action called
`push_command_to(pipeline)`.
And I believe it will make our life easier to support something like
`o>> a.txt`, `e>> a.txt`.
In the final match of `lex_item`, we'll return `Err(ParseError)` in rare
case, normally we'll return None.
So I think making error part mutable can reduce some code, and it's
better if we want to add more lex items.
# Description
just caught a last mention to `let-env` in the `CONTRIBUTING.md`
document 😋
# User-Facing Changes
# Tests + Formatting
# After Submitting
# Description
This PR updates the release-pkg.nu script with updated instructions for
performing the release manually. These are there specifically because
winget fails so often and creating a x86_64 windows msi is not trivial.
There are also a couple minor changes to the script's syntax.
# 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 std testing; testing run-tests --path
crates/nu-std"` 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
Files that begin with dashes can be ambiguous when passed to commands
like `ls`. For example if there exists a file `--help`, it might be
considered a flag if not properly escaped. This PR escapes any file that
begins with a dash.
# User-Facing Changes
Files beginning with dashes will be escaped.
# Tests + Formatting
Tests are added.
(squashed version of #10557, clean commit history and review thread)
Fixes#10571, also potentially: #10364, #10211, #9558, #9310,
# Description
Changes processing of arguments to filesystem commands that are source
paths or globs.
Applies to `cp, cp-old, mv, rm, du` but not `ls` (because it uses a
different globbing interface) or `glob` (because it uses a different
globbing library).
The core of the change is to lookup the argument first as a file and
only glob if it is not. That way,
a path containing glob metacharacters can be referenced without glob
quoting, though it will have to be single quoted to avoid nushell
parsing.
Before: A file path that looks like a glob is not matched by the glob
specified as a (source) argument and takes some thinking about to
access. You might say the glob pattern shadows a file with the same
spelling.
```
> ls a*
╭───┬────────┬──────┬──────┬────────────────╮
│ # │ name │ type │ size │ modified │
├───┼────────┼──────┼──────┼────────────────┤
│ 0 │ a[bc]d │ file │ 0 B │ 34 seconds ago │
│ 1 │ abd │ file │ 0 B │ now │
│ 2 │ acd │ file │ 0 B │ now │
╰───┴────────┴──────┴──────┴────────────────╯
> cp --verbose 'a[bc]d' dest
copied /home/bobhy/src/rust/work/r4/abd to /home/bobhy/src/rust/work/r4/dest/abd
copied /home/bobhy/src/rust/work/r4/acd to /home/bobhy/src/rust/work/r4/dest/acd
> ## Note -- a[bc]d *not* copied, and seemingly hard to access.
> cp --verbose 'a\[bc\]d' dest
Error: × No matches found
╭─[entry #33:1:1]
1 │ cp --verbose 'a\[bc\]d' dest
· ─────┬────
· ╰── no matches found
╰────
> #.. but is accessible with enough glob quoting.
> cp --verbose 'a[[]bc[]]d' dest
copied /home/bobhy/src/rust/work/r4/a[bc]d to /home/bobhy/src/rust/work/r4/dest/a[bc]d
```
Before_2: if file has glob metachars but isn't a valid pattern, user
gets a confusing error:
```
> touch 'a[b'
> cp 'a[b' dest
Error: × Pattern syntax error near position 30: invalid range pattern
╭─[entry #13:1:1]
1 │ cp 'a[b' dest
· ──┬──
· ╰── invalid pattern
╰────
```
After: Args to cp, mv, etc. are tried first as literal files, and only
as globs if not found to be files.
```
> cp --verbose 'a[bc]d' dest
copied /home/bobhy/src/rust/work/r4/a[bc]d to /home/bobhy/src/rust/work/r4/dest/a[bc]d
> cp --verbose '[a][bc]d' dest
copied /home/bobhy/src/rust/work/r4/abd to /home/bobhy/src/rust/work/r4/dest/abd
copied /home/bobhy/src/rust/work/r4/acd to /home/bobhy/src/rust/work/r4/dest/acd
```
After_2: file with glob metachars but invalid pattern just works.
(though Windows does not allow file name to contain `*`.).
```
> cp --verbose 'a[b' dest
copied /home/bobhy/src/rust/work/r4/a[b to /home/bobhy/src/rust/work/r4/dest/a[b
```
So, with this fix, a file shadows a glob pattern with the same spelling.
If you have such a file and really want to use the glob pattern, you
will have to glob quote some of the characters in the pattern. I think
that's less confusing to the user: if ls shows a file with a weird name,
s/he'll still be able to copy, rename or delete it.
# User-Facing Changes
Could break some existing scripts. If user happened to have a file with
a globbish name but was using a glob pattern with the same spelling, the
new version will process the file and not expand the glob.
# 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 std testing; testing run-tests --path
crates/nu-std"` 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.
-->
Fix winget release submission error, more details could be found here:
https://github.com/nushell/nushell/pull/5812#issuecomment-1768294811
@fdncred @wolimst
# 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 std testing; testing run-tests --path
crates/nu-std"` 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>
# Description
This PR is just a quick change to add `coreutils` to the `cp` command. I
thought that it would be a good search term as we start to integrate
more `coreutils` commands.
# 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 std testing; testing run-tests --path
crates/nu-std"` to run the tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
This PR adds a new command called `debug info`. I'm not sure if the name
is right but we can rename it if needed. The purpose of this command is
to show a user how much memory nushell is using. This is what the output
looks like.
I feel like the further we go with nushell, the more we'll need to
easily monitor the memory usage. With this command, we should easily be
able to do that with scripts or just running the command.
```nushell
❯ debug info | table -e
╭─────────┬──────────────────────────────────────────────────────────────────────╮
│pid │31036 │
│ppid │29388 │
│ │╭─────────────────┬────────────────────────────────────────────────╮ │
│process ││memory │63.5 MB │ │
│ ││virtual_memory │5.6 GB │ │
│ ││status │Runnable │ │
│ ││root │C:\cartar\debug │ │
│ ││cwd │C:\Users\us991808\source\repos\forks\nushell\ │ │
│ ││exe_path │C:\cartar\debug\nu.exe │ │
│ ││command │c:\cartar\debug\nu.exe -l │ │
│ ││name │nu.exe │ │
│ ││environment │{record 110 fields} │ │
│ │╰─────────────────┴────────────────────────────────────────────────╯ │
│ │╭────────────────┬───────╮ │
│system ││total_memory │17.1 GB│ │
│ ││free_memory │5.9 GB │ │
│ ││used_memory │11.3 GB│ │
│ ││available_memory│5.9 GB │ │
│ │╰────────────────┴───────╯ │
╰─────────┴──────────────────────────────────────────────────────────────────────╯
```
> [!NOTE]
The `process.environment` is not the nushell `$env` but the environment
that the process was created with at launch time.
# 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 std testing; testing run-tests --path
crates/nu-std"` 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!
-->
Refer to
https://github.com/nushell/nushell/pull/10600#issuecomment-1762863791
# 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 path is escaped when it can be entirely parsed as a floating point
number. This includes `nan`, `inf` and their negative counterparts since
nu also supports them.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Paths with numbers that cannot be ambiguous are no longer surrounded by
backticks.
# 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 std testing; testing run-tests --path
crates/nu-std"` 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 allows `open` to handle files with multiple extensions; i.e it
will try to call `from tar.gz`, `from gz` when calling
```nu
open file.tar.gz
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes.
# Description
After the addition of the prefix tab completion support, the older
`partial_from` function is left with a single invocation. This PR moves
the code inside the function to the point of invocation.
# User-Facing Changes
No user facing changes.
# Tests + Formatting
Tests are passing.
Fixes#10696
# Description
As reported, you could mess up the ring of remembered directories in
`std dirs` (a.k.a the `shells` commands) with a sequence like this:
```
~/test> mkdir b c
~/test> pushd b
~/test/b> cd ../c
~/test/c> goto 0
~/test> goto 1
## expect to end up in ~/test/c
## observe you're in ~/test/b
~/test/b>
```
Problem was `dirs goto` was not updating the remembered directories
before leaving the current slot for some other. This matters if the user
did a manual `cd` (which cannot update the remembered directories ring)
# User-Facing Changes
None! it just works ™️
# Tests + Formatting
- 🟢 `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.
-->
Re-fixes #3674, if that is seen as desirable to do.
# Description
This PR changes the implementation of the `--features=extra` string
casing commands from Inflector to `heck`, as in PR #4081. This PR landed
a long time ago, but somewhere along the way (i can't find it) the
implementation ended up being switched back to Inflector.
# User-Facing Changes
Inflector and `heck` implement casing differently, so all of the
commands have different behavior around edge cases (consecutive
capitals, interspersed numbers and letters, etc)
### Before
```nu
G:/Dev/nu-itself/nushell> [UserID ABCdefGHI foo123bar] | str camel-case
╭───┬───────────╮
│ 0 │ userID │
│ 1 │ abcdefGHI │
│ 2 │ foo123Bar │
╰───┴───────────╯
G:/Dev/nu-itself/nushell> [UserID ABCdefGHI foo123bar] | str snake-case
╭───┬─────────────╮
│ 0 │ user_id │
│ 1 │ ab_cdef_ghi │
│ 2 │ foo_12_3bar │
╰───┴─────────────╯
```
### After
```nu
G:/Dev/nu-itself/nushell> [UserID ABCdefGHI foo123bar] | str camel-case
╭───┬───────────╮
│ 0 │ userId │
│ 1 │ abCdefGhi │
│ 2 │ foo123bar │
╰───┴───────────╯
G:/Dev/nu-itself/nushell> [UserID ABCdefGHI foo123bar] | str snake-case
╭───┬─────────────╮
│ 0 │ user_id │
│ 1 │ ab_cdef_ghi │
│ 2 │ foo123bar │
╰───┴─────────────╯
```
# Tests + Formatting
The existing string casing tests pass... because none of them relied on
any of these edge cases
# Description
Open question:
Undocumented behavior for the new argument `ambiguous` to the
`as_datetime`
methods. I cheated by passing a default (assuming empty string).
This appears like an API primarily serving the python impl:
https://pola-rs.github.io/polars/py-polars/html/reference/expressions/api/polars.Expr.str.to_datetime.html#polars-expr-str-to-datetime
# User-Facing Changes
Only dependent on breaking changes to the behavior of polars.
# Tests + Formatting
No observed changes to tests
Manually checked `dfr as-datetime`, doesn't seem to panic.
# Description
Those commands either only return `Type::Float` or `Type::Int`
Narrow the type to the correct output
# User-Facing Changes
More correct type in documentation
# Description
This PR changes `Type::Float` to point at `SyntaxShape::Float` instead
of `SyntaxShape::Number`.
# 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 std testing; testing run-tests --path
crates/nu-std"` 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 changes the `canonicalize_ndots` tests (renames to
canonicalize_ndots2) so that when it's checking for
`canonicalize_with("...", cwd)` it guarantees it begins in a more deeply
nested folder. I was having problems because my new DevDrive is on
D:\nushell and it can't do `cd ...` from that folder.
# 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 std testing; testing run-tests --path
crates/nu-std"` 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 will only display the list of subcommands.
Prompted by a question on Discord why completions may be missing.
With standard completion settings getting the subcommands doesn't seem
to be a problem but we could add this command for good measure.
# User-Facing Changes
New command `dfr` that does nothing apart from displaying the
subcommands and hogging a space in the completions
# Tests + Formatting
(-)
# Description
This PR renames nushell's `cp` command to `cp-old` to make room for
`ucp` to be renamed to `cp`, making the coreutils version of `cp` the
default for nushell. After some period of time, we should remove
`cp-old` entirely.
# 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 std testing; testing run-tests --path
crates/nu-std"` 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.
-->
followup to
- https://github.com/nushell/nushell/pull/9979
## ⚠️ wait for just before 0.86 ⚠️
# Description
after deprecation comes removal 😏
# User-Facing Changes
`into decimal` is removed in favor of `into float`
# Tests + Formatting
# After Submitting
# Description
Fix#10506 by adding `ExpectedNonNull` `ShellError` if required field is
entered as `$nothing`, `null`, " ", etc.
This adds a new `ShellError`, `ExpectedNonNull`, taking the expected
type and span.
# User-Facing Changes
Will get a more helpful error in the case described by #10506. Examples:
```nushell
➜ {scheme: "", host: "github.com"} | url join
Error: nu:🐚:expected_non_null
× Expected string found null.
╭─[entry #16:1:1]
1 │ {scheme: "", host: "github.com"} | url join
· ─┬
· ╰── expected string, found null
╰────
```
```nushell
❯ {scheme: "https", host: null} | url join
Error: nu:🐚:expected_non_null
× Expected string found null.
╭─[entry #19:1:1]
1 │ {scheme: "https", host: null} | url join
· ──┬─
· ╰── expected string, found null
╰────
```
# Tests + Formatting
All pass.
followup to
- https://github.com/nushell/nushell/pull/9979
## ⚠️ wait for just before 0.86 ⚠️
# Description
after deprecation comes removal 😏
# User-Facing Changes
`into decimal` is removed in favor of `into float`
# Tests + Formatting
# After Submitting
# Description
The issue #10318 is resolved by introducing helper methods within the
existing `get_documentation` function in the nu-engine crate. Initially,
I considered using nu-color-config crate to convert HEX config color to
ANSI color and employing the following method
[https://github.com/nushell/nushell/blob/main/crates/nu-color-config/src/color_config.rs#L9C1-L20C2](https://github.com/nushell/nushell/blob/main/crates/nu-color-config/src/color_config.rs#L9C1-L20C2).
However, this approach was deemed impractical due to circular
dependencies. Consequently, in a manner akin to how we invoke the
`table` command from the nu-command crate in `get_documentation`
function to create a themed-colored table, we invoke the `ansi` command
from nu-command to obtain the ANSI theme color code.
# User-Facing Changes
Visual Changes Only: the help command now uses configured theme, else it
falls back on default hard coded values.
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` 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.
-->
I wondered why this test failed for me.
Turns out my config file is not compatible with current main, but the
error message was useless. I've added `--no-config-file`
related to
-
https://discord.com/channels/601130461678272522/615329862395101194/1159484770468773990
# Description
because the following might not be trivial
```nushell
> "/foo/bar" | path join "/" "baz"
/baz
```
i thought adding a few examples to the `path join` command might help
😇
# User-Facing Changes
two new examples in `help path join` one with `..` and the other with
`/` 👍
# Tests + Formatting
the examples have `result`s so that they are checked.
# After Submitting
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
- fixes#10649
# 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
Tab completions for paths starting with `./` shall have the prefix
preserved.
<!-- 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 std testing; testing run-tests --path
crates/nu-std"` to run the tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
This pr fix clippy warnings in latest clippy version(1.72.0):
Unfortunally it's not easy to handle for [try
fold](https://rust-lang.github.io/rust-clippy/master/index.html#/manual_try_fold)
warning in `start command`
Refer to known issue:
> This lint doesn’t take into account whether a function does something
on the failure case, i.e., whether short-circuiting will affect
behavior. Refactoring to try_fold is not desirable in those cases.
That's the case for our code, which does something on the failure case.
So this pr is making a little refactor on `try_commands`.
