Commit Graph

365 Commits

Author SHA1 Message Date
ba59f71f20 bump to dev version 0.105.2 (#15952)
# 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.
-->
2025-06-12 07:57:01 -05:00
1fe62ee613 bump patch version 2025-06-10 21:42:41 +02:00
ebcdf5a8b1 Bump to 0.105.0 (#15930)
<!--
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
Bump to 0.105.0
2025-06-10 23:37:00 +08:00
f92f11c0cf Enable shell_integration.osc9_9 by default on Windows (#15914)
# 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.
2025-06-08 07:29:49 -05:00
65c9160170 Fix typo in example config.nu (#15910) 2025-06-07 13:51:07 +08:00
c10e483683 Bump dev version to 0.104.2 (#15809)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Bump dev version to 0.104.2
2025-05-24 00:54:33 +08:00
c4dcfdb77b feat!: Explicit cell-path case sensitivity syntax (#15692)
Related:
- #15683
- #14551
- #849
- #12701
- #11527

# Description
Currently various commands have differing behavior regarding cell-paths

```nushell
{a: 1, A: 2} | get a A
# => ╭───┬───╮
# => │ 0 │ 2 │
# => │ 1 │ 2 │
# => ╰───┴───╯
{a: 1, A: 2} | select a A
# => ╭───┬───╮
# => │ a │ 1 │
# => │ A │ 2 │
# => ╰───┴───╯
{A: 1} | update a 2
# => Error: nu:🐚:column_not_found
# => 
# =>   × Cannot find column 'a'
# =>    ╭─[entry #62:1:1]
# =>  1 │ {A: 1} | update a 2
# =>    · ───┬──          ┬
# =>    ·    │            ╰── cannot find column 'a'
# =>    ·    ╰── value originates here
# =>    ╰────
```

Proposal: making cell-path access case-sensitive by default and adding
new syntax for case-insensitive parts, similar to optional (?) parts.

```nushell
{FOO: BAR}.foo
# => Error: nu:🐚:name_not_found
# => 
# =>   × Name not found
# =>    ╭─[entry #60:1:21]
# =>  1 │ {FOO: BAR}.foo
# =>    ·            ─┬─
# =>    ·             ╰── did you mean 'FOO'?
# =>    ╰────
{FOO: BAR}.foo!
# => BAR
```

This would solve the problem of case sensitivity for all commands
without causing an explosion of flags _and_ make it more granular

Assigning to a field using a case-insensitive path is case-preserving.
```nushell
mut val = {FOO: "I'm FOO"}; $val
# => ╭─────┬─────────╮
# => │ FOO │ I'm FOO │
# => ╰─────┴─────────╯
$val.foo! = "I'm still FOO"; $val
# => ╭─────┬───────────────╮
# => │ FOO │ I'm still FOO │
# => ╰─────┴───────────────╯
```

For `update`, case-insensitive is case-preserving.
```nushell
{FOO: 1} | update foo! { $in + 1 }
# => ╭─────┬───╮
# => │ FOO │ 2 │
# => ╰─────┴───╯
```

`insert` can insert values into nested values so accessing into existing
columns is case-insensitive, but creating new columns uses the cell-path
as it is.
So `insert foo! ...` and `insert FOO! ...` would work exactly as they do
without `!`
```nushell
{FOO: {quox: 0}}
# => ╭─────┬──────────────╮
# => │     │ ╭──────┬───╮ │
# => │ FOO │ │ quox │ 0 │ │
# => │     │ ╰──────┴───╯ │
# => ╰─────┴──────────────╯
{FOO: {quox: 0}} | insert foo.bar 1
# => ╭─────┬──────────────╮
# => │     │ ╭──────┬───╮ │
# => │ FOO │ │ quox │ 0 │ │
# => │     │ ╰──────┴───╯ │
# => │     │ ╭─────┬───╮  │
# => │ foo │ │ bar │ 1 │  │
# => │     │ ╰─────┴───╯  │
# => ╰─────┴──────────────╯
{FOO: {quox: 0}} | insert foo!.bar 1
# => ╭─────┬──────────────╮
# => │     │ ╭──────┬───╮ │
# => │ FOO │ │ quox │ 0 │ │
# => │     │ │ bar  │ 1 │ │
# => │     │ ╰──────┴───╯ │
# => ╰─────┴──────────────╯
```

`upsert` is tricky, depending on the input, the data might end up with
different column names in rows. We can either forbid case-insensitive
cell-paths for `upsert` or trust the user to keep their data in a
sensible shape.

This would be a breaking change as it would make existing cell-path
accesses case-sensitive, however the case-sensitivity is already
inconsistent and any attempt at making it consistent would be a breaking
change.

> What about `$env`?

1. Initially special case it so it keeps its current behavior.
2. Accessing environment variables with non-matching paths gives a
deprecation warning urging users to either use exact casing or use the
new explicit case-sensitivity syntax
3. Eventuall remove `$env`'s special case, making `$env` accesses
case-sensitive by default as well.

> `$env.ENV_CONVERSIONS`?

In addition to `from_string` and `to_string` add an optional field to
opt into case insensitive/preserving behavior.

# User-Facing Changes

- `get`, `where` and other previously case-insensitive commands are now
case-sensitive by default.
- `get`'s `--sensitive` flag removed, similar to `--ignore-errors` there
is now an `--ignore-case` flag that treats all parts of the cell-path as
case-insensitive.
- Users can explicitly choose the case case-sensitivity of cell-path
accesses or commands.

# Tests + Formatting

Existing tests required minimal modification. ***However, new tests are
not yet added***.

- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib

# After Submitting

- Update the website to include the new syntax
- Update [tree-sitter-nu](https://github.com/nushell/tree-sitter-nu)

---------

Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
2025-05-18 12:19:09 +03:00
c2ac8f730e Rust 1.85, edition=2024 (#15741) 2025-05-13 16:49:30 +02:00
cb133ed387 feat(table): Add new 'single' table mode (#15672)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->
closes #15381

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Adds a new table mode called `single`, it looks like the `heavy` mode,
but the key difference is that it uses thinner lines. I decided on the
name `single` because it's one of the border styles Neovim uses, and
they look practically the same.

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->

New config option:

```nushell
$env.config.table.mode = 'single'
```

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Added new tests in `crates/nu-table/tests/style.rs` to cover the single
table mode.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-05-01 15:30:57 -05:00
eadb8da9f7 Bump to 0.104.1 dev version (#15669)
Marks development or hotfix
2025-04-29 23:33:10 -04:00
cda15d91dd Bump version for 0.104.0 release (#15664) 2025-04-29 19:31:45 -04:00
d8bec8668f feat(table): make missing value symbol configurable (#15647)
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
2025-04-27 22:58:39 +02:00
61dbcf3de6 Substring Match Algorithm (#15511)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR should close #15474 .

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
When users set the match algorithm to 'substring' by modifying
`$env.config` to `$env.config.completions.algorithm = "substring"``),
completions are done based on substring matches.
This was previously possible by setting `positional` to be false in
custom completers, but doing so now logs a warning as this feature is
set to be deprecated and replaced by the new way of setting the matching
algorithm to substring based.
2025-04-11 05:15:36 -04:00
ca4222277e Fix typo in doc_config.nu + small description (#15461)
# 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.
2025-03-31 21:38:50 +02:00
07be33c119 fix(nu-command): support ACL, SELinux, e.g. in cd have_permission check (#15360)
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>
2025-03-27 14:23:41 +01:00
7c160725ed Rename user-facing 'date' to 'datetime' (#15264)
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`
2025-03-21 13:36:21 -04:00
2c7ab6e898 Bump to 0.103.1 dev version (#15347)
# Description

Marks development or hotfix
2025-03-19 00:12:01 -04:00
c986426478 Bump version for 0.103.0 release (#15340) 2025-03-18 20:12:52 -04:00
95dcb2fd6c Add filesize.show_unit config option (#15276)
# Description

Continuation of #15271. This PR adds the
`$env.config.filesize.show_unit` option to allow the ability to omit the
filesize unit. Useful if `$env.config.filesize.unit` is set to a fixed
unit, and you don't want the same unit repeated over and over.

# User-Facing Changes

- Adds the `$env.config.filesize.show_unit` option.
2025-03-09 17:34:55 -05:00
d97b2e3c60 Respect system locale when formatting file sizes via config (#15271)
# Description

Commands and other pieces of code using `$env.config.format.filesize` to
format filesizes now respect the system locale when formatting the
numeric portion of a file size.

# User-Facing Changes

- System locale is respected when using `$env.config.format.filesize` to
format file sizes.
- Formatting a file size with a binary unit is now exact for large file
sizes and units.
- The output of `to text` is no longer dependent on the config.
2025-03-09 15:43:02 -05:00
1d44843970 Remove inheritance for PROMPT variables created in default_env.nu (#15130)
This PR always sets a fresh `PROMPT_COMMAND` and `PROMPT_COMMAND_RIGHT`
during startup in `default_env.nu`. This is a more "sensible default",
and can then be overridden with user config later in the startup.
2025-02-21 10:08:10 -05:00
2cb059146b Add buffer_editor example with arguments in config nu --doc (#15122)
Counterpart to https://github.com/nushell/nushell.github.io/pull/1810 -
Adds an example to the `config nu --doc` for using a `buffer_editor`
with arguments.

Closes https://github.com/nushell/nushell.github.io/issues/1660 and
resolves the main issue in #14893, but we'll leave it open based on
[this
suggestion](https://github.com/nushell/nushell/issues/14893#issuecomment-2607670442)
2025-02-14 18:51:54 -05:00
d4aeadbb44 Enable theming the Welcome Banner (#15095)
The banner will now use three new `$env.config.color_config` settings:
- `banner_foreground`: The primary color of the banner text
- `banner_highlight1`: Used for the first set of highlights, e.g.,
`Nushell`, `nu`, `GitHub`, et. al
- `banner_highlight2`: Used for the second set of highlights, e.g.
`Discord`, `Documentation`, et. al.

If the settings above are not defined, `banner` continues to use the
default green/purple/foreground. However, two more lines use the
purple/highlight2 in order to give more separation and consistency to
the colorization.
2025-02-14 10:19:16 -05:00
803a348f41 Bump to 0.102.1 dev version (#15012) 2025-02-05 00:19:48 -05:00
1aa2ed1947 Bump version to 0.102.0 (#14998) 2025-02-04 10:49:35 -05:00
339c5b7c83 fix: clippy warning of rust 1.8.4 (#14984)
# Description

I'm on rust toolchain 1.8.4, and I can see clippy warnings that can't be
caught by the ci workflow, primarily related to lifetime params.

I think it doesn't hurt to fix those in advance.

# User-Facing Changes

# Tests + Formatting

# After Submitting
2025-02-02 07:56:54 -06:00
93e121782c Improve and fix filesize formatting/display (#14397)
# Description

This PR cleans up the code surrounding formatting and displaying file
sizes.
- The `byte_unit` crate we use for file size units displays kilobytes as
`KB`, which is not the SI or ISO/IEC standard. Rather it should be `kB`,
so this fixes #8872. On some systems, `KB` actually means `KiB`, so this
avoids any potential confusion.
- The `byte_unit` crate, when displaying file sizes, casts integers to
floats which will lose precision for large file sizes. This PR adds a
custom `Display` implementation for `Filesize` that can give an exact
string representation of a `Filesize` for metric/SI units.
- This PR also removes the dependency on the `byte_unit` crate which
brought in several other dependencies.

Additionally, this PR makes some changes to the config for filesize
formatting (`$env.config.filesize`).
- The previous filesize config had the `metric` and `format` options. If
a metric (SI) unit was set in `format`, but `metric` was set to false,
then the `metric` option would take precedence and convert `format` to
the corresponding binary unit (or vice versa). E.g., `{ format: kB,
metric: false }` => `KiB`. Instead, this PR adds the `unit` option to
replace the `format` and `metric` options. `unit` can be set to a fixed
file size unit like `kB` or `KiB`, or it can be set to one of the
special options: `binary` or `metric`. These options tells nushell to
format file sizes using an appropriately scaled metric or binary unit
(examples below).
  ```nushell
  # precision = null

  # unit = kB
  1kB  # 1 kB
  1KiB # 1.024 kB
  
  # unit = KiB
  1kB  # 0.9765625 KiB
  1KiB # 1 KiB
  
  # unit = metric
  1000B     # 1 kB
  1024B     # 1.024 kB
  10_000MB  # 10 GB
  10_240MiB # 10.73741824 GB

  # unit = binary
  1000B     # 1000 B
  1024B     # 1 KiB
  10_000MB  # 9.313225746154785 GiB
  10_240MiB # 10 GiB
  ```
- In addition, this PR also adds the `precision` option to the filesize
config. It determines how many digits to show after the decimal point.
If set to null, then everything after the decimal point is shown.
- The default filesize config is `{ unit: metric, precision: 1 }`.

# User-Facing Changes

- Commands that use the config to format file sizes will follow the
changes described above (e.g., `table`, `into string`, `to text`, etc.).
- The file size unit/format passed to `format filesize` is now case
sensitive. An error with the valid units is shown if the case does not
match.
- `$env.config.filesize.format` and `$env.config.filesize.metric` are
deprecated and replaced by `$env.config.filesize.unit`.
- A new `$env.config.filesize.precision` option was added.

# Tests + Formatting

Mostly updated test expected outputs.

# After Submitting

This PR does not change the way NUON serializes file sizes, because that
would require changing the nu parser to be able to losslessly decode the
new, exact string representation introduced in this PR.

Similarly, this PR also does not change the file size parsing in any
way. Although the file size units provided to `format filesize` or the
filesize config are now case-sensitive, the same is not yet true for
file size literals in nushell code.
2025-01-22 22:24:51 -08:00
5f3c8d45d8 Add auto option for config.use_ansi_coloring (#14647)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->

In this PR I continued the idea of #11494, it added an `auto` option to
the ansi coloring config option, I did this too but in a more simple
approach.

So I added a new enum `UseAnsiColoring` with the three values `True`,
`False` and `Auto`. When that value is set to `auto`, the default value,
it will use `std::io::stdout().is_terminal()` to decided whether to use
ansi coloring. This allows to dynamically decide whether to print ansi
color codes or not, [cargo does it the same
way](652623b779/src/bin/cargo/main.rs (L72)).
`True` and `False` act as overrides to the `is_terminal` check. So with
that PR it is possible to force ansi colors on the `table` command or
automatically remove them from the miette errors if no terminal is used.

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->

Terminal users shouldn't be affected by this change as the default value
was `true` and `is_terminal` returns for terminals `true` (duh).
Non-terminal users, that use `nu` in some embedded way or the engine
implemented in some other way (like my jupyter kernel) will now have by
default no ansi coloring and need to enable it manually if their
environment allows it.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->

The test for fancy errors expected ansi codes, since tests aren't run
"in terminal", the ansi codes got stripped away.
I added a line that forced ansi colors above it. I'm not sure if that
should be the case or if we should test against no ansi colors.

- 🟢 `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.
-->

This should resolve #11464 and partially #11847. This also closes
#11494.
2024-12-26 11:00:01 -06:00
d3cbcf401f Bump version to 0.101.1 (#14661) 2024-12-24 23:47:00 +01:00
fb26109049 Bump version for 0.101.0 release (#14631)
It's palindromic!
2024-12-22 15:10:19 +01:00
e0685315b4 tweaks to config flatten (#14639)
# Description

@maxim-uvarov found some bugs in the new `config flatten` command. This
PR should take care of what's been identified so far.

# 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.
-->
2024-12-19 17:26:21 -06:00
b48f50f018 Remove unused sample_login.nu file (#14632)
This file is not made accessible to the user through any of our `config`
commands.
Thus I discussed with Douglas to delete it, to ensure it doesn't go out
of date (the version added with #14601 was not yet part of the bumping
script)

All the necessary information on how to setup a `login.nu` file is
provided in the website documentation
2024-12-19 20:21:52 +01:00
f2e8c391a2 lookup closures/blockids and get content in config flatten (#14635)
# Description

This PR continues to tweak `config flatten` by looking up the closures
and block_ids and extracts the content into the produced record.

Example

![image](https://github.com/user-attachments/assets/99a9db54-e477-40b2-8468-bbadcf0aa5b7)


# 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.
-->
2024-12-19 08:43:49 -06:00
bf8763fc11 Add shape_garbage (#14626)
# Description

Adds `$env.config.color_config.shape_garbage` to the default config so
that it is populated out of the box.

Thanks to @PerchunPak for finding that it was missing.

# User-Facing Changes

I think this is useful on two levels, but it will be a change for a lot
of users:

1. Accessing it won't generate an error out-of-the-box
2. Garbage errors are highlighted in reverse-red in real-time in the
REPL. This means that, for example, typing just a `$` will start out as
an error - Once a valid variable (e.g., `$env`) is completed, then the
highlight will change to the parsed shape.

# Tests + Formatting

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

# After Submitting

N/A
2024-12-18 19:43:26 -06:00
8f4feeb119 add config flatten command (#14621)
# Description

This is supposed to be a Quality-of-Life command that just makes some
things easier when dealing with a nushell config. Really all it does is
show you the current config in a flattened state. That's it. I was
thinking this could be useful when comparing config settings between old
and new config files. There are still room for improvements. For
instance, closures are listed as an int. They can be updated with a
`view source <int>` pipeline but that could all be built in too.


![image](https://github.com/user-attachments/assets/5d8981a3-8d03-4eb3-8361-2f3c3c560660)

The command works by getting the current configuration, serializing it
to json, then flattening that json. BTW, there's a new flatten_json.rs
in nu-utils. Theoretically all this mess could be done in a custom
command script, but it's proven to be exceedingly difficult based on the
work from discord.

Here's some more complex items to flatten.

![image](https://github.com/user-attachments/assets/b44e2ec8-cf17-41c4-bf8d-7f26317db071)

# 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.
-->
2024-12-18 15:50:16 -06:00
99fe866d12 Remove duplicate version line (#14611)
# Description

Fixed:

* `version = "0.100.1"` line got duplicated during merge conflict
resolution - Found while updating `bump_version.nu`.

# User-Facing Changes

N/A

# Tests + Formatting

TODO

# After Submitting

N/A
2024-12-17 16:08:20 -06:00
c0ad659985 Doc file fixes (#14608)
# Description

With great thanks to @fdncred and especially @PerchunPak (see #14601)
for finding and fixing a number of issues that I pulled in here due to
the filename changes and upcoming freeze.

This PR primarily fixes a poor wording choice in the new filenames and
`config` command options. The fact that these were called
`sample_config.nu` (etc.) and accessed via `config --sample` created a
great deal of confusion. These were never intended to be used as-is as
config files, but rather as in-shell documentation.

As such, I've renamed them:

* `sample_config.nu` becomes `doc_config.nu`
* `sample_env.nu` becomes `doc_env.nu`
* `config nu --sample` becomes `config nu --doc`
* `config env --sample` because `config env --doc`

Also the following:

* Updates `doc_config.nu` with a few additional comment-fixes on top of
@PerchunPak's changes.
* Adds version numbers to all files - Will need to update the version
script to add some files after this PR.
* Additional doc on plugin and plugin_gc configuration which I had
failed to previously completely update from the older wording
* Updated the comments in the `scaffold_*.nu` files to point people to
`help config`/`help nu` so that, if things change in the future, it will
become more difficult for the comments to be outdated.
* 

# User-Facing Changes

Mostly doc.

`config nu` and `config env` changes update new behavior previously
added in 0.100.1

# Tests + Formatting

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

# After Submitting

* Update configuration chapter of doc
* Update the blog entry on migrating config
* Update `bump-version.nu`
2024-12-17 14:18:23 -06:00
cc4da104e0 Fix issues in the example configs (#14601)
For some reason, it had multiple syntax errors and other issues, like
undefined options. Would be great to add a test for sourcing all example
configs, but I don't know rust

See also
https://github.com/nushell/nushell/pull/14249#discussion_r1887192408

<!--
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!
-->

CC @NotTheDr01ds
2024-12-17 10:43:25 -06:00
6367fb6e9e Add missing color_config settings (#14603)
# Description

Fixes #14600 by adding a default value for missing keys in
`default_config.nu`:

* `$env.config.color_config.glob`
* `$env.config.color_config.closure`

# User-Facing Changes

Will no longer error when accessing these keys.

# Tests + Formatting

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

# After Submitting

N/A
2024-12-16 18:20:54 -06:00
39770d4197 Moves additional env vars out of default_env and updates some transient prompt vars (#14579)
# Description

With `NU_LIB_DIRS`, `NU_PLUGIN_DIRS`, and `ENV_CONVERSIONS` now moved
out of `default_env.nu`, we're down to just a few left. This moves all
non-closure `PROMPT` variables out as well (and into Rust `main()`. It
also:

* Implements #14565 and sets the default
`TRANSIENT_PROMPT_COMMAND_RIGHT` and `TRANSIENT_MULTILINE_INDICATOR` to
an empty string so that they are removed for easier copying from the
terminal.
* Reverses portions of #14249 where I was overzealous in some of the
variables that were imported
* Fixes #12096 
* Will be the final fix in place, I believe, to close #13670

# User-Facing Changes

Transient prompt will now remove the right-prompt and
multiline-indicator once a commandline has been entered.

# Tests + Formatting

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
- 
# After Submitting

Release notes addition
2024-12-16 08:18:47 -06:00
7aacad3270 Set empty ENV_CONVERSIONS record by default (#14566)
# Description

With Windows Path case-insensitivity in place, we no longer need an
`ENV_CONVERSIONS` for `PATH`, as the
`nu_engine::env::convert_env_values()` handles it automatically.

This PR:

* Removes the default `ENV_CONVERSIONS` for path from `default_env.nu`
* Sets `ENV_CONVERSIONS` to an empty record (so it can be `merge`'d) in
`main()` instead

# User-Facing Changes

No behavioral changes - Users will now have an empty `ENV_CONVERSIONS`
at startup by default, but the behavior should not change.

# Tests + Formatting

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

# After Submitting
2024-12-12 10:50:28 -06:00
035b882db1 Update sample and scaffold files (#14568)
# Description

Tidying up some of the wording of the sample and scaffold files to align
with our current recommendations:

* Continue to generate a commented-only `env.nu` and `config.nu` on
first launch.
* The generated `env.nu` mentions that most configuration can be done in
`config.nu`
* The `sample_env.nu` mentions the same. I might try getting rid of
`config env --sample` entirely (it's new since 0.100 anyway).
* All configuration is now documented "in-shell" in `sample_config.nu`,
which can be viewed using `config nu --sample` - This means that
environment variables that used to be in `sample_env.nu` have been moved
to `sample_config.new`.

# User-Facing Changes

Doc-only

# Tests + Formatting

Doc-only changes, but:

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

# After Submitting

Need to work on updates to Config chapter
2024-12-12 10:43:20 -06:00
0872e9c3ae Allow both NU_PLUGIN_DIRS const and env at the same time (#14553)
# Description

Fix #14544 and is also the reciprocal of #14549.

Before: If both a const and env `NU_PLUGIN_DIRS` were defined at the
same time, the env paths would not be used.
After: The directories from `const NU_PLUGIN_DIRS` are searched for a
matching filename, and if not found, `$env.NU_PLUGIN_DIRS` directories
will be searched.

Before: `$env.NU_PLUGIN_DIRS` was unnecessary set both in main() and in
default_env.nu
After: `$env.NU_PLUGIN_DIRS` is only set in main()

Before: `$env.NU_PLUGIN_DIRS` was set to `plugins` in the config
directory
After: `$env.NU_PLUGIN_DIRS` is set to an empty list and `const
NU_PLUGIN_DIRS` is set to the directory above.

Also updates `sample_env.nu` to use the `const`

# User-Facing Changes

Most scenarios should work just fine as there continues to be an
`$env.NU_PLUGIN_DIRS` to append to or override.

However, there is a small chance of a breaking change if someone was
*querying* the old default `$env.NU_PLUGIN_DIRS`.

# Tests + Formatting

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

Also updated the `env` tests and added one for the `const`.

# After Submitting

Config doc updates
2024-12-11 11:41:06 -06:00
cf82814606 Use const NU_LIB_DIRS in startup (#14549)
# Description

A slower, gentler alternative to #14531, in that we're just moving one
setting *out* of `default_env.nu` in this PR ;-).

All this does is transition from using `$env.NU_LIB_DIRS` in the startup
config to `const $NU_LIB_DIRS`. Also updates the `sample_env.nu` to
reflect the changes.

Details:

Before: `$env.NU_LIB_DIRS` was unnecessary set both in `main()` and in
`default_env.nu`
After: `$env.NU_LIB_DIRS` is only set in `main()`

Before: `$env.NU_LIB_DIRS` was set to `config-dir/scripts` and
`data-dir/completions`
After: `$env.NU_LIB_DIRS` is set to an empty list, and `const
NU_LIB_DIRS` is set to the directories above

Before: Using `--include-path (-I)` would set the `$env.NU_LIB_DIRS`
After: Using `--include-path (-I)` sets the constant `$NU_LIB_DIRS`

# User-Facing Changes

There shouldn't be any breaking changes here. The `$env.NU_LIBS_DIRS`
still works for most cases. There are a few areas we need to clean-up to
make sure that the const is usable (`nu-check`, et. al.) but they will
still work in the meantime with the older `$env` version.

# Tests + Formatting

* Changed the Type-check on the `$env` version.
* Added a type check for the const version.

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

# After Submitting

Doc updates
2024-12-10 06:36:05 -06:00
3d5f853b03 Start to Add WASM Support Again (#14418)
<!--
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 [nushell/demo](https://github.com/nushell/demo) project successfully
demonstrated running Nushell in the browser using WASM. However, the
current version of Nushell cannot be easily built for the
`wasm32-unknown-unknown` target, the default for `wasm-bindgen`.

This PR introduces initial support for the `wasm32-unknown-unknown`
target by disabling OS-dependent features such as filesystem access, IO,
and platform/system-specific functionality. This separation is achieved
using a new `os` feature in the following crates:

 - `nu-cmd-lang`
 - `nu-command`
 - `nu-engine`
 - `nu-protocol`

The `os` feature includes all functionality that interacts with an
operating system. It is enabled by default, but can be disabled using
`--no-default-features`. All crates that depend on these core crates now
use `--no-default-features` to allow compilation for WASM.

To demonstrate compatibility, the following script builds all crates
expected to work with WASM. Direct user interaction, running external
commands, working with plugins, and features requiring `openssl` are out
of scope for now due to their complexity or reliance on C libraries,
which are difficult to compile and link in a WASM environment.

```nushell
[ # compatible crates
	"nu-cmd-base",
	"nu-cmd-extra",
	"nu-cmd-lang",
	"nu-color-config",
	"nu-command",
	"nu-derive-value",
	"nu-engine",
	"nu-glob",
	"nu-json",
	"nu-parser",
	"nu-path",
	"nu-pretty-hex",
	"nu-protocol",
	"nu-std",
	"nu-system",
	"nu-table",
	"nu-term-grid",
	"nu-utils",
	"nuon"
] | each {cargo build -p $in --target wasm32-unknown-unknown --no-default-features}
```

## Caveats
This PR has a few caveats:
1. **`miette` and `terminal-size` Dependency Issue**
`miette` depends on `terminal-size`, which uses `rustix` when the target
is not Windows. However, `rustix` requires `std::os::unix`, which is
unavailable in WASM. To address this, I opened a
[PR](https://github.com/eminence/terminal-size/pull/68) for
`terminal-size` to conditionally compile `rustix` only when the target
is Unix. For now, the `Cargo.toml` includes patches to:
    - Use my forked version of `terminal-size`.
- ~~Use an unreleased version of `miette` that depends on
`terminal-size@0.4`.~~

These patches are temporary and can be removed once the upstream changes
are merged and released.

2. **Test Output Adjustments**
Due to the slight bump in the `miette` version, one test required
adjustments to accommodate minor formatting changes in the error output,
such as shifted newlines.

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
This shouldn't break anything but allows using some crates for targeting
`wasm32-unknown-unknown` to revive the demo page eventually.

# 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`

I did not add any extra tests, I just checked that compiling works, also
when using the host target but unselecting the `os` feature.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
~~Breaking the wasm support can be easily done by adding some `use`s or
by adding a new dependency, we should definitely add some CI that also
at least builds against wasm to make sure that building for it keep
working.~~
I added a job to build wasm.

---------

Co-authored-by: Ian Manske <ian.manske@pm.me>
2024-11-30 07:57:11 -06:00
acca56f77c Remove unused FlatShapes And/Or (#14476)
# Description
This removes the need for the `shape_and` and `shape_or` entries in the
themes. We did not color those underlying FlatShapes or operators
differently.

Closes #14372
# User-Facing Changes
Our theme handling currently doesn't reject invalid entries so should
not cause an error. The non-functional nature was already documented.
2024-11-29 22:23:40 +01:00
8d1e36fa3c Allow inherited environment variables (#14467)
# Description

Due to #14249 loading `default_env.nu` before the user's `env.nu`,
variables that were defined there were overriding:

* Inherited values
* Some values that were set in the Rust code, such as the `NU_LIB_PATH`
when set using `--include-path`.

This change checks to see if a variable already exists, uses its value
if so, and sets the default value otherwise.

Note: `ENV_CONVERSIONS` is still "forced" to a default value regardless,
as it needs to run reliably. There's probably not much reason to inherit
it, but I'm open to the idea if there's a use-case.

# User-Facing Changes

* Before: Variables that were set in `default_env.nu` always overrode
those that were inherited from the parent process or set internally
* After: Inherited and internal environment variables will take
priority.

# Tests + Formatting

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

# After Submitting

Will try to find a good place to mention this behavior in the Config
chapter updates
2024-11-28 12:37:32 -06:00
bccff3b237 Update default-files README (#14461)
# Description

Someone noticed today that I had left a TODO in the Readme. It has since
been completed and needed to be removed. Also made some other minor
fixes and wordsmithing while I was in it.

# User-Facing Changes

None

# Tests + Formatting

Clippy and fmt passed, and that should be all that matters on the
Readme.

# After Submitting

N/A
2024-11-28 15:04:42 +08:00
e0c0d39ede deprecate --ignore-shell-errors and --ignore-program-errors in do (#14385)
# Description
As title, this pr is going to deprecate `--ignore-shell-errors` and
`--ignore-program-errors`.

Because I think these two flags makes `do` command complicate, and it
should be easy to use `-i` instead.

# User-Facing Changes
After the pr, using these two flags will raise deprecated warning.
```nushell
> do --ignore-program-errors { ^pwd }
Error:   × Deprecated option
   ╭─[entry #2:1:1]
 1 │ do --ignore-program-errors { ^pwd }
   · ─┬
   ·  ╰── `--ignore-program-errors` is deprecated and will be removed in 0.102.0.
   ╰────
  help: Please use the `--ignore-errors(-i)`
/home/windsoilder/projects/nushell
> do --ignore-shell-errors { ^pwd }
Error:   × Deprecated option
   ╭─[entry #3:1:1]
 1 │ do --ignore-shell-errors { ^pwd }
   · ─┬
   ·  ╰── `--ignore-shell-errors` is deprecated and will be removed in 0.102.0.
   ╰────
  help: Please use the `--ignore-errors(-i)`
/home/windsoilder/projects/nushell
```

# Tests + Formatting
NaN
2024-11-27 09:36:30 +08:00
7a9b14b49d Add example for PROMPT_COMMAND_RIGHT (#14439)
# Description

I just completely left out `$env.PROMPT_COMMAND_RIGHT` in the
`sample_env.nu`. This adds it in.

# User-Facing Changes

`config env --sample` will now include doc for `PROMPT_COMMAND_RIGHT`.

# Tests + Formatting

Doc-only

# After Submitting

n/a
2024-11-25 19:25:43 -06:00