Hello, this PR resolves the second request of the issue
https://github.com/nushell/nushell/issues/10957, which involves using a
default verb based on the request. If a URL is provided, the command
will default to GET, and if data is provided, it will default to POST.
This means that the following pairs of commands are equivalent:
```
http --content-type application/json http://localhost:8000 {a:1}
http post --content-type application/json http://localhost:8000 {a:1}
```
```
http http://localhost:8000 "username"
http post http://localhost:8000 "username"
```
```
http http://localhost:8000
http get http://localhost:8000
```
The `http` command now accepts all flags of the `post` and `get`
commands. It will still display the help message if no subcommand is
provided, and the description has been updated accordingly. The logic in
the `http` command is minimal to delegate error management
responsibilities to the specific `run_get` and `run_post` functions.
# Description
Based on some testing in
[Discord](https://discord.com/channels/601130461678272522/1349836000804995196/1353138803640111135)
we were able to find that `insert` and `delete` happening at the same
time caused problems in the `stor` command. So, I added `conn.is_busy()`
with a sleep to try and avoid that problem.
/cc @NotTheDr01ds @132ikl
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
I've noticed that unlike everything else in nushell the output of `ansi
--list` has a column named `short name` instead of `short_name`, so I
changed it. While I was at it, I also added a shortname `rst` to `reset`
since it is often used.
# User-Facing Changes
Changed the column name of `ansi --list` from `short name` to
`short_name`
# Description
I have added a `--no-prefix` flag to the `format number` command to not
include the `0b`, `0x` and `0o` prefixes in the output. Also, I've
changed the order in which the formats are displayed to one I thinks
makes it easier to read, with the upper and lower alternatives next to
each other.
# User-Facing Changes
The formatting of floats previously did not include prefixes while
integers did. Now prefixes are on by default for both, while including
the new flag removes them. Changing the order of the record shouldn't
have any effect on previous code.
# Tests + Formatting
I have added an additional example that test this behavior.
# After Submitting
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
# Description
Fixes the issue of listing allowed datatypes when not being used with
dataframe pipeline input.
Co-authored-by: Jack Wright <jack.wright@nike.com>
# Description
`polars last` will only return one row by default making it consistent
with `polars first`
# User-Facing Changes
- `polars last` will only return one row by default making it consistent
with `polars first`
Co-authored-by: Jack Wright <jack.wright@nike.com>
# Description
This PR adds `like` and `not-like` to the `help operators` command. Now
it at least lists them. I wasn't sure if I should say `=~ or like` so I
just separated them with a comma.
# 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
Promotes the clip module from `std-rfc` to `std`. Whether we want to
promote other modules as well (probably?) is up for discussion but I
thought I would get the ball rolling with this one.
# User-Facing Changes
* The `clip` module has been promoted from `std-rfc` to `std`. Using the
`std-rfc` version of clip modules will give a deprecation warning
instructing you to switch to the `std` version.
# Tests + Formatting
N/A
# After Submitting
N/A
# Description
Closes#15848. Currently, we expand unquoted strings to absolute paths
if they are of type `path` or `directory`. This PR makes this no longer
happen. `~`, `.`, and `..+` are still expanded, but a path like
`.../foo/bar/..` will only be turned into `../../foo`, rather than a
full absolute path.
This is mostly so that paths don't get modified before being sent to
known external commands (as in the linked issue). But also, it seems
unnecessary to make all unquoted paths absolute.
After feedback from @132ikl, this PR also makes it so that unquoted
paths are expanded at parse time, so that it matches the runtime
behavior. Previously, `path` expressions were turned into strings
verbatim, while `directory` expressions were treated as not being const.
API change: `nu_path::expansions::expand_path` is now exposed as
`nu_path::expand_path`.
# User-Facing Changes
This has the potential to silently break a lot of scripts. For example,
if someone has a command that expects an already-expanded absolute path,
changes the current working directory, and then passes the path
somewhere, they will now need to use `path expand` to expand the path
themselves before changing the current working directory.
# Tests + Formatting
Just added one test to make sure unquoted `path` arguments aren't made
absolute.
# After Submitting
This is a breaking change, so will need to be mentioned in the release
notes.
# Description
This PR makes the last specified CLI arguments take precedence over the
earlier ones.
Existing command line tools that align with the new behaviour include:
- `neovim`: `nvim -u a.lua -u b.lua` will use `b.lua`
- `ripgrep`: you can have `--smart-case` in your user config but
override it later with `--case-sensitive` or `--ignore-case` (not
exactly the same flag override as the one I'm talking about but I think
it's still a valid example of latter flags taking precedence over the
first ones)
I think a flag defined last can be considered an override. This allows
having a `nu` alias that includes some default config (`alias nu="nu
--config something.nu"`) but being able to override that default config
as if using `nu` normally.
## Example
```sh
nu --config config1.nu --config config2.nu -c '$nu.config-path'
```
The current behavior would print `config1.nu`, and the new one would
print `config2.nu`
## Implementation
Just `.rev()` the iterator to search for arguments starting from the end
of the list. To support that I had to modify the return type of
`named_iter` (I couldn't find a more generic way than
`DoubleEndedIterator`).
# User-Facing Changes
- Users passing repeated flags and relying in nushell using the first
value will experience breakage. Given that right now there's no point in
passing a flag multiple times I guess not many users will be affected
# Tests + Formatting
I added a test that checks the new behavior with `--config` and
`--env-config`. I'm happy to add more cases if needed
# After Submitting
# Description
When attempting to pass a null byte in a commandline argument, Nu
currently fails with:
```
> ^echo (char -i 0)
Error: nu:🐚:io::invalid_input
× I/O error
╰─▶ × Could not spawn foreground child
╭────
1 │ crates/nu-command/src/system/run_external.rs:284:17
· ─────────────────────────┬─────────────────────────
· ╰── Invalid input parameter
╰────
```
This does not explain which input parameter is invalid, or why. Since Nu
does not typically seem to escape null bytes when printing values
containing them, this can make it a bit tricky to track down the
problem.
After this change, it fails with:
```
> ^echo (char -i 0)
Error: nu:🐚:io::invalid_input
× I/O error
╰─▶ × Could not spawn foreground child: nul byte found in provided data
╭────
1 │ crates/nu-command/src/system/run_external.rs:282:17
· ─────────────────────────┬─────────────────────────
· ╰── Invalid input parameter
╰────
```
which is more useful. This could be improved further but this is niche
enough that is probably not necessary.
This might make some other errors unnecessarily verbose but seems like
the better default. I did check that attempting to execute a
non-executable file still has a reasonable error: the error message for
that failure is not affected by this change.
It is still an "internal" error (referencing the Nu code triggering it,
not the user's input) because the `call.head` span available to this
code is for the command, not its arguments. Using it would result in
```
× I/O error
╰─▶ × Could not spawn foreground child: nul byte found in provided data
╭─[entry #1:1:2]
1 │ ^echo (char -i 0)
· ──┬─
· ╰── Invalid input parameter
╰────
```
which is actively misleading because "echo" does not contain the nul
byte.
# 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
> ```
-->
Haven't tried to write a test yet: it's tricky because the better error
message comes from the Rust stdlib (so a straightforward integration
test checking for the specific message would be brittle)...
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
Closes: #15755
I think it's a good feature, to achieve this, we need to get all hidden
envs(it's defined in `get_hidden_env_vars`, and then restore these envs
back to stack)
# User-Facing Changes
### Before
```nushell
> $env.foo = 'bar'
> overlay new xxx
> hide-env foo
> overlay hide xxx
> $env.foo
Error: nu:🐚:column_not_found
× Cannot find column 'foo'
╭─[entry #21:5:1]
4 │ overlay hide xxx
5 │ $env.foo
· ────┬───┬
· │ ╰── value originates here
· ╰── cannot find column 'foo'
╰────
```
### After
```nushell
> $env.foo = 'bar'
> overlay new xxx
> hide-env foo
> overlay hide xxx
> $env.foo
bar
```
## Note
But it doesn't work if it runs the example code in script:
`nu -c "$env.foo = 'bar'; overlay new xxx; hide-env foo; overlay hide
xxx; $env.foo"`
still raises an error says `foo` doesn't found. That's because if we run
the script at once, the envs in stack doesn't have a chance to merge
back into `engine_state`, which is only called in `repl`.
It introduces some sort of inconsistency, but I think users use overlays
mostly in repl, so it's good to have such feature first.
# Tests + Formatting
Added 2 tests
# After Submitting
NaN
Bumps [which](https://github.com/harryfei/which-rs) from 7.0.0 to 7.0.3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/harryfei/which-rs/releases">which's
releases</a>.</em></p>
<blockquote>
<h2>7.0.3</h2>
<ul>
<li>Update rustix to version 1.0. Congrats to rustix on this milestone,
and thanks <a href="https://github.com/mhils"><code>@mhils</code></a>
for this contribution to which!</li>
</ul>
<h2>7.0.2</h2>
<ul>
<li>Don't return paths containing the single dot <code>.</code>
reference to the current directory, even if the original request was
given in terms of the current directory. Thanks <a
href="https://github.com/jakobhellermann"><code>@jakobhellermann</code></a>
for this contribution!</li>
</ul>
<h2>7.0.1</h2>
<h2>What's Changed</h2>
<ul>
<li>Switch to <code>env_home</code> crate by <a
href="https://github.com/micolous"><code>@micolous</code></a> in <a
href="https://redirect.github.com/harryfei/which-rs/pull/105">harryfei/which-rs#105</a></li>
<li>fixes <a
href="https://redirect.github.com/harryfei/which-rs/issues/106">#106</a>,
bump patch version by <a
href="https://github.com/Xaeroxe"><code>@Xaeroxe</code></a> in <a
href="https://redirect.github.com/harryfei/which-rs/pull/107">harryfei/which-rs#107</a></li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a href="https://github.com/micolous"><code>@micolous</code></a>
made their first contribution in <a
href="https://redirect.github.com/harryfei/which-rs/pull/105">harryfei/which-rs#105</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/harryfei/which-rs/compare/7.0.0...7.0.1">https://github.com/harryfei/which-rs/compare/7.0.0...7.0.1</a></p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/harryfei/which-rs/blob/master/CHANGELOG.md">which's
changelog</a>.</em></p>
<blockquote>
<h2>7.0.3</h2>
<ul>
<li>Update rustix to version 1.0. Congrats to rustix on this milestone,
and thanks <a href="https://github.com/mhils"><code>@mhils</code></a>
for this contribution to which!</li>
</ul>
<h2>7.0.2</h2>
<ul>
<li>Don't return paths containing the single dot <code>.</code>
reference to the current directory, even if the original request was
given in
terms of the current directory. Thanks <a
href="https://github.com/jakobhellermann"><code>@jakobhellermann</code></a>
for this contribution!</li>
</ul>
<h2>7.0.1</h2>
<ul>
<li>Get user home directory from <code>env_home</code> instead of
<code>home</code>. Thanks <a
href="https://github.com/micolous"><code>@micolous</code></a> for this
contribution!</li>
<li>If home directory is unavailable, do not expand the tilde to an
empty string. Leave it as is.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="1d145deef8"><code>1d145de</code></a>
release version 7.0.3</li>
<li><a
href="f5e5292234"><code>f5e5292</code></a>
fix unrelated lint error</li>
<li><a
href="4dcefa6fe9"><code>4dcefa6</code></a>
bump rustix</li>
<li><a
href="bd868818bd"><code>bd86881</code></a>
bump version, add to changelog</li>
<li><a
href="cf37760ea1"><code>cf37760</code></a>
don't run relative dot test on macos</li>
<li><a
href="f2c4bd6e8b"><code>f2c4bd6</code></a>
update target to new name for wasm32-wasip1</li>
<li><a
href="87acc088c1"><code>87acc08</code></a>
When searching for <code>./script.sh</code>, don't return
<code>/path/to/./script.sh</code></li>
<li><a
href="68acf2c456"><code>68acf2c</code></a>
Fix changelog to link to GitHub profile</li>
<li><a
href="b6754b2a56"><code>b6754b2</code></a>
Update CHANGELOG.md</li>
<li><a
href="0c63719129"><code>0c63719</code></a>
fixes <a
href="https://redirect.github.com/harryfei/which-rs/issues/106">#106</a>,
bump patch version</li>
<li>Additional commits viewable in <a
href="https://github.com/harryfei/which-rs/compare/7.0.0...7.0.3">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [ansi-str](https://github.com/zhiburt/ansi-str) from 0.8.0 to
0.9.0.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/zhiburt/ansi-str/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Description
I was messing around with custom types and noticed `nu-protocol`
referring to a `Value::CustomValue` variant that doesn't exist. Fixed it
to say `Value::Custom` instead.
# User-Facing Changes
Documentation mentions the correct variant of `Value`
# Tests + Formatting
No new tests necessary
# After Submitting
- improves rounding error reported in #15851
- my ~~discussion~~ monologue on how filesizes are parsed currently:
#15944
# Description
The issue linked above reported rounding errors when converting MiB to
GiB, which is mainly caused by parsing of the literal.
Nushell tries to convert all filesize values to bytes, but currently
does so in 2 steps:
- first converting it to the next smaller unit in `nu-parser` (so `MiB`
to `KiB`, in this case), and truncating to an `i64` here
- then converting that to bytes in `nu-engine`, again truncating to
`i64`
In the specific example above (`95307.27MiB`), this causes 419 bytes of
rounding error. By instead directly converting to bytes while parsing,
the value is accurate (truncating those 0.52 bytes, or 4.12 bits).
Rounding error in the conversion to GiB is also multiple magnitudes
lower.
(Note that I haven't thoroughly tested this, so I can't say with
confidence that all values would be parsed accurate to the byte.)
# User-Facing Changes
More accurate filesize values, and lower accumulated rounding error in
calculations.
# Tests + Formatting
new test: `parse_filesize` in `nu-parser` - verifies that `95307.27MiB`
is parsed correctly as `99_936_915_947B`
# After Submitting
# Description
Bump nushell to development version.
# 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.
-->
Use NUSHELL_PAT for winget publish
Closes#14552
# Description
Implemented a new flag to the ```to md``` command to center specific
columns in Markdown table output using a list of CellPaths.
This enhances formatting control for users exporting tables to markdown.
## Example
For the table:
```shell
let t = version | select version build_time | transpose k v
```
```
╭───┬────────────┬────────────────────────────╮
│ # │ k │ v │
├───┼────────────┼────────────────────────────┤
│ 0 │ version │ 0.104.1 │
│ 1 │ build_time │ 2025-05-21 11:15:45 +01:00 │
╰───┴────────────┴────────────────────────────╯
```
Running ```$t | to md``` or ```$t | to md --pretty``` gives us,
respectively:
```
|k|v|
|-|-|
|version|0.104.1|
|build_time|2025-05-21 11:15:45 +01:00|
```
|k|v|
|-|-|
|version|0.104.1|
|build_time|2025-05-21 11:15:45 +01:00|
and
```
| k | v |
| ---------- | -------------------------- |
| version | 0.104.1 |
| build_time | 2025-05-21 11:15:45 +01:00 |
```
| k | v |
| ---------- | -------------------------- |
| version | 0.104.1 |
| build_time | 2025-05-21 11:15:45 +01:00 |
With the new ```center``` flag, when adding ```--center [v]``` to the
previous commands, we obtain, respectively:
```
|k|v|
|-|:-:|
|version|0.104.1|
|build_time|2025-05-21 11:15:45 +01:00|
```
|k|v|
|-|:-:|
|version|0.104.1|
|build_time|2025-05-21 11:15:45 +01:00|
and
```
| k | v |
| ---------- |:--------------------------:|
| version | 0.104.1 |
| build_time | 2025-05-21 11:15:45 +01:00 |
```
| k | v |
| ---------- |:--------------------------:|
| version | 0.104.1 |
| build_time | 2025-05-21 11:15:45 +01:00 |
The new ```center``` option, as demonstrated in the example, not only
formats the Markdown table to center columns but also, when paired with
```pretty```, it also centers the string values within those columns.
The logic works by extracting the column from the CellPath and applying
centering. So, ```--center [1.v]``` is also valid and centers the
```v``` column.
You can also specify multiple columns, for instance, ```--center [v
k]``` will center both columns in the example above.
# User-Facing Changes
The ```to md``` command will support column centering with the new
```center``` flag.
# Tests + Formatting
Added test cases to ensure correct behaviour.
fmt + clippy OK.
# After Submitting
The command documentation needs to be updated with the new ```center```
flag and an example.
Co-authored-by: Marco Cunha <marcomarquesdacunha@tecnico.ulisboa.pt>
Co-authored-by: Marco Cunha <marcomarquesdacunha@tecnico.ulisboa.pt>
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Try to fix PAT issue of `winget` publish account, this change may make
publish with `nushell` account work
# Description
This PR fixes a `date humanize` bug and makes it use @LoicRiegel's newer
function `human_time_from_now()`.
### Before
```nushell
❯ (date now) + 3day
Wed, 11 Jun 2025 07:15:48 -0500 (in 3 days)
❯ (date now) + 3day | date humanize
in 2 days
```
### After
```nushell
❯ (date now) + 3day
Wed, 11 Jun 2025 07:23:10 -0500 (in 3 days)
❯ (date now) + 3day | date humanize
in 3 days
```
Closes#15916
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
# Description
This sets the value to true by default only on Windows. This is not a
legacy code and is used by the Windows Terminal to detect the current
directory (explicitly enabling osc7 did not work). Here are the official
docs:
https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory
# User-Facing Changes
Windows users will by default have their terminals properly detect the
current working directory without extra configuration/troubleshooting.
To check https://github.com/nushell/reedline/pull/916
As this is the only commit since the last release, if problems are
encountered for Nushell we can revert this and forgo a reedline release
---------
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.
-->
The current implementation of `polars pivot` calls an unsupported
version of pivot that throws a warning message in stdout (using
println!) stating that "unstable pivot not yet unsupported, using stable
pivot." This PR swaps out the call to `pivot` with a call to
`pivot_stable`, which is being done in the underlying polars anyways.
```nushell
# Current Implementation
> [[a b c]; [1 x 10] [1 y 10] [2 x 11] [2 y 11]] | polars into-df | polars pivot -i [a] -o [b] -v [c]
unstable pivot not yet supported, using stable pivot
╭───┬───┬────┬────╮
│ # │ a │ x │ y │
├───┼───┼────┼────┤
│ 0 │ 1 │ 10 │ 10 │
│ 1 │ 2 │ 11 │ 11 │
# Proposed Implementation (no println! statement)
> [[a b c]; [1 x 10] [1 y 10] [2 x 11] [2 y 11]] | polars into-df | polars pivot -i [a] -o [b] -v [c]
╭───┬───┬────┬────╮
│ # │ a │ x │ y │
├───┼───┼────┼────┤
│ 0 │ 1 │ 10 │ 10 │
│ 1 │ 2 │ 11 │ 11 │
╰───┴───┴────┴────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
None
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Current suite of tests were sufficient
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
- basically reverts #15657
- still fixes#15584
- fixes#15784
- related https://github.com/tafia/calamine/pull/506
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
The `zip` crate had some issues properly upgrading their repo and did
some yanking shenanigans. Since their yanking took so long `calamine`
tried to fix it but right now pinned to a yanked version of `zip`. This
breaks `cargo update`, `cargo add nu_command` and forces installs to use
`--locked`. For `calamine` exists [a
PR](https://github.com/tafia/calamine/pull/506) that would fix this but
right now that is not merged and we don't know when. Since we only
bumped `calamine` to fix#15584 and with the correctly yanked
`zip@2.5.0` we don't have that issue anymore. So I'm basically reverting
our `calamine` version. As soon as `calamine` updates with the new
version of `zip`, we can bump it again.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Should be none.
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
If dependabot tries to bump `calamine` to `0.27.0`, we have to closed
that PR.
# Description
Updates `help where` to better explain row conditions, and provide more
examples. Also, the syntax shape is changed to `one_of(condition,
closure())>`. I don't think this should affect parsing at all because it
should still always be parsed as `SyntaxShape::RowCondition`, but it
should be more clear that you can use a row condition _or_ a closure
here, even if technically we consider closures to be row conditions
internally. In a similar vein, the help text makes this distinction
explicitly to make it more clear to users that closures are supported.
# User-Facing Changes
* Updated `where` help text
---------
Co-authored-by: Bahex <Bahex@users.noreply.github.com>
Co-authored-by: Douglas <32344964+NotTheDr01ds@users.noreply.github.com>
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
- Updated the second @example for `find` to "Try to find an even
element" to match the closure logic.
- Updated the second @example for `find-index` to "Try to find the index
of an even element" for consistency.
I did a naive fix; which is probably all right.
But I want to spend some time to refactor a neighboring stuff.
And it's yet not to be released I guess;
I hope to add a few things beforehand.
I've just opened it so you can verify that it must be addressed.
close#15104, #14910, #15256
# Description
This PR fixes drive-letter glob expansion on Windows. It adds a bit of
pre-processing to play better with the wax crate.
This change is following suggestions from this thread on the wax repo:
https://github.com/olson-sean-k/wax/issues/34fixes#15707#7125
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Fixes#15884.
Adds `--disable-tag` flag to the `gstat` plugin that disables expensive
calculations. Instead `gstat` reports `no_tag`.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
There is no change in behaviour if the flag is not provided.
If the flag is provided, it will behave like there is no tags in the
repo, so no existing config will break.
**Title**: Better error handling for negative integer exponents in `**`
operator
---
### Bug Fix
This PR addresses an issue where attempting to raise an integer to a
negative power (e.g. `10 ** -1`) incorrectly triggered an
`OperatorOverflow` error. This behavior was misleading since the
overflow isn't actually the root problem — it's the unsupported
operation of raising integers to negative powers.
---
### Fix Summary
* Updated `Value::pow` to:
* Check for negative exponents when both operands are integers.
* Return a `ShellError::IncorrectValue` with a helpful message guiding
users to use floating point values instead.
#### Example:
```bash
> 10 ** -1
Error: nu:🐚:incorrect_value
× Incorrect value.
╝─[entry #2:1:4]
1 │ 10 ** -1
· ─┬┬
· │╰── encountered here
· ╰── Negative exponent for integer power is unsupported; use floats instead.
```
---
### Testing
Manual testing:
* `10 ** -1` → now returns a clear and appropriate `IncorrectValue`
error.
* `10.0 ** -1`, `10 ** -1.0`, etc. continue to work as expected.
---
### Related
Fixes#15860
---------
Co-authored-by: Kumar Ujjawal <kumar.ujjawal@greenpista.com>
