# Description
#14019 deprecated the `split-by` command. This sets its doc-category to
"deprecated" so that it will display that way in the in-shell and online
help
# User-Facing Changes
`split-by` will now show as a deprecated command in Help. Will also be
reported using:
```nushell
help commands | where category == deprecated
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
N/A
# Description
There is an opportunity to give a bogus block id to view source. This
makes it more resilient and not panic when an invalid block id is passed
in.
![image](https://github.com/user-attachments/assets/67ebbffc-be57-4ce3-8700-90f1ed080f9b)
# 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 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.
-->
# Description
This PR is meant to add another nushell introspection/debug command,
`view blocks`. This command shows what is in the EngineState's memory
that is parsed and stored as blocks. Blocks may continue to grow as you
use the repl.
![image](https://github.com/user-attachments/assets/8a19fd56-ef15-4993-9700-a51eb8eaec7f)
# 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 PR adds the `merge deep` command. This allows you to merge nested
records and tables/lists within records together, instead of overwriting
them. The code for `merge` was reworked to support more general merging
of values, so `merge` and `merge deep` use the same underlying code.
`merge deep` mostly works like `merge`, except it recurses into inner
records which exist in both the input and argument rather than just
overwriting. For lists and by extension tables, `merge deep` has a
couple different strategies for merging inner lists, which can be
selected with the `--strategy` flag. These are:
- `table`: Merges tables element-wise, similarly to the merge command.
Non-table lists are not merged.
- `overwrite`: Lists and tables are overwritten with their corresponding
value from the argument, similarly to scalars.
- `append`: Lists and tables in the input are appended with the
corresponding list from the argument.
- `prepend`: Lists and tables in the input are prepended with the
corresponding list from the argument.
This can also be used with the new config changes to write a monolithic
record of _only_ the config values you want to change:
```nushell
# in config file:
const overrides = {
history: {
file_format: "sqlite",
isolation: true
}
}
# use append strategy for lists, e.g., menus keybindings
$env.config = $env.config | merge deep --strategy=append $overrides
# later, in REPL:
$env.config.history
# => ╭───────────────┬────────╮
# => │ max_size │ 100000 │
# => │ sync_on_enter │ true │
# => │ file_format │ sqlite │
# => │ isolation │ true │
# => ╰───────────────┴────────╯
```
<details>
<summary>Performance details</summary>
For those interested, there was less than one standard deviation of
difference in startup time when setting each config item individually
versus using <code>merge deep</code>, so you can use <code>merge
deep</code> in your config at no measurable performance cost. Here's my
results:
My normal config (in 0.101 style, with each `$env.config.[...]` value
updated individually)
```nushell
bench --pretty { ./nu -l -c '' }
# => 45ms 976µs 983ns +/- 455µs 955ns
```
Equivalent config with a single `overrides` record and `merge deep -s
append`:
```nushell
bench --pretty { ./nu -l -c '' }
# => 45ms 587µs 428ns +/- 702µs 944ns
```
</details>
Huge thanks to @Bahex for designing the strategies API and helping
finish up this PR while I was sick ❤️
Related: #12148
# User-Facing Changes
Adds the `merge deep` command to recursively merge records. For example:
```nushell
{a: {foo: 123 bar: "overwrite me"}, b: [1, 2, 3]} | merge deep {a: {bar: 456, baz: 789}, b: [4, 5, 6]}
# => ╭───┬───────────────╮
# => │ │ ╭─────┬─────╮ │
# => │ a │ │ foo │ 123 │ │
# => │ │ │ bar │ 456 │ │
# => │ │ │ baz │ 789 │ │
# => │ │ ╰─────┴─────╯ │
# => │ │ ╭───┬───╮ │
# => │ b │ │ 0 │ 4 │ │
# => │ │ │ 1 │ 5 │ │
# => │ │ │ 2 │ 6 │ │
# => │ │ ╰───┴───╯ │
# => ╰───┴───────────────╯
```
`merge deep` also has different strategies for merging inner lists and
tables. For example, you can use the `append` strategy to _merge_ the
inner `b` list instead of overwriting it.
```nushell
{a: {foo: 123 bar: "overwrite me"}, b: [1, 2, 3]} | merge deep --strategy=append {a: {bar: 456, baz: 789}, b: [4, 5, 6]}
# => ╭───┬───────────────╮
# => │ │ ╭─────┬─────╮ │
# => │ a │ │ foo │ 123 │ │
# => │ │ │ bar │ 456 │ │
# => │ │ │ baz │ 789 │ │
# => │ │ ╰─────┴─────╯ │
# => │ │ ╭───┬───╮ │
# => │ b │ │ 0 │ 1 │ │
# => │ │ │ 1 │ 2 │ │
# => │ │ │ 2 │ 3 │ │
# => │ │ │ 3 │ 4 │ │
# => │ │ │ 4 │ 5 │ │
# => │ │ │ 5 │ 6 │ │
# => │ │ ╰───┴───╯ │
# => ╰───┴───────────────╯
```
**Note to release notes writers**: Please credit @Bahex for this PR as
well 😄
# 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 tests for deep merge
- 🟢 `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.
-->
N/A
---------
Co-authored-by: Bahex <bahey1999@gmail.com>
# 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`
# Description
This PR allows the `view source` command to view source based on an int
value. I wrote this specifically to be able to see closures where the
text is hidden. For example:
![image](https://github.com/user-attachments/assets/d8fe2692-0951-4366-9cb9-55f20044b68a)
And then you can use those `<Closure #>` with the `view source` command
like this.
![image](https://github.com/user-attachments/assets/f428c8ad-56a9-4e72-880e-e32fb9155531)
# 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
Add tests for `path self`.
I wasn't very familiar with the code base, especially the testing
utilities, when I first implemented `path self`. It's been on my mind to
add tests for it since then.
# Description
`from ...` conversions pass along all metadata except `content_type`,
which they set to `None`.
## Rationale
`open`ing a file results in no `content_type` metadata if it can be
parsed into a nu data structure, and using `open --raw` results in
`content_type` metadata.
`from ...` commands should preserve metadata ***except*** for
`content_type`, as after parsing it's no longer that `content_type` and
just structured nu data.
These commands should return identical data *and* identical metadata
```nushell
open foo.csv
```
```nushell
open foo.csv --raw | from csv
```
# User-Facing Changes
N/A
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
# Description
A lot of filter commands that have a closure argument (`each`, `filter`,
etc), have a wrong signature for the closure, indicating an extra int
argument for the closure.
I think they are a left over from before `enumerate` was added, used to
access iteration index. None of the commands changed in this PR actually
supply this int argument.
# User-Facing Changes
N/A
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
# Description
Add an example to `reduce` that shows accumulator can also be accessed
pipeline input.
# User-Facing Changes
N/A
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
Fixes#14554
# User-Facing Changes
Raw strings are now supported in match patterns:
```diff
match "foo" { r#'foo'# => true, _ => false }
-false
+true
```
<!--
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#14567
Now NuShell's `exec` command will decrement `SHLVL` env value before
passing it to target executable.
It only works in interactive session, the same as `SHLVL`
initialization.
In addition, this PR also make a simple change to `SHLVL` initialization
(only remove an unnecessary type conversion).
# 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
> ```
-->
Formatted.
With interactively tested with several shells (bash, zsh, fish) and
cross-exec-ing them, it works well this time.
# 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: #14387
~To make it happen, just need to added `-l` flag to `du`, and pass it to
`DirBuilder`, `DirInfo`, `FileInfo`
Then tweak `impl From<DirInfo> for Value` and `impl From<FileInfo> for
Value` impl.~
---
Edit: this PR is going to:
1. Exclude directories and files columns by default
2. Added `-l/--long` flag to output directories and files columns
3. When running `du`, it will output the files as well. Previously it
doesn't output the size of file.
To make it happen, just need to added `-r` flag to `du`, and pass it to
`DirBuilder`, `DirInfo`, `FileInfo`
Then tweak `impl From<DirInfo> for Value` and `impl From<FileInfo> for
Value` impl.
And rename some variables.
# User-Facing Changes
`du` is no longer output `directories` and `file` columns by default,
added `-r` flag will show `directories` column, `-f` flag will show
`files` column.
```nushell
> du nushell
╭───┬────────────────────────────────────┬──────────┬──────────╮
│ # │ path │ apparent │ physical │
├───┼────────────────────────────────────┼──────────┼──────────┤
│ 0 │ /home/windsoilder/projects/nushell │ 34.6 GiB │ 34.7 GiB │
├───┼────────────────────────────────────┼──────────┼──────────┤
│ # │ path │ apparent │ physical │
╰───┴────────────────────────────────────┴──────────┴──────────╯
> du nushell --recursive --files # It outputs two more columns, `directories` and `files`, but the output is too long to paste here.
```
# Tests + Formatting
Added 1 test
# After Submitting
NaN
# Description
Before this PR, `help commands` uses the name from a command's
declaration rather than the name in the scope. This is problematic when
trying to view the help page for the `main` command of a module. For
example, `std bench`:
```nushell
use std/bench
help bench
# => Error: nu::parser::not_found
# =>
# => × Not found.
# => ╭─[entry #10:1:6]
# => 1 │ help bench
# => · ──┬──
# => · ╰── did not find anything under this name
# => ╰────
```
This can also cause confusion when importing specific commands from
modules. Furthermore, if there are multiple commands with the same name
from different modules, the help text for _both_ will appear when
querying their help text (this is especially problematic for `main`
commands, see #14033):
```nushell
use std/iter
help iter find
# => Error: nu::parser::not_found
# =>
# => × Not found.
# => ╭─[entry #3:1:6]
# => 1│ help iter find
# => · ────┬────
# => · ╰── did not find anything under this name
# => ╰────
help find
# => Searches terms in the input.
# =>
# => Search terms: filter, regex, search, condition
# =>
# => Usage:
# => > find {flags} ...(rest)
# [...]
# => Returns the first element of the list that matches the
# => closure predicate, `null` otherwise
# [...]
# (full text omitted for brevity)
```
This PR changes `help commands` to use the name as it is in scope, so
prefixing any command in scope with `help` will show the correct help
text.
```nushell
use std/bench
help bench
# [help text for std bench]
use std/iter
help iter find
# [help text for std iter find]
use std
help std bench
# [help text for std bench]
help std iter find
# [help text for std iter find]
```
Additionally, the IR code generation for commands called with the
`--help` text has been updated to reflect this change.
This does have one side effect: when a module has a `main` command
defined, running `help <name>` (which checks `help aliases`, then `help
commands`, then `help modules`) will show the help text for the `main`
command rather than the module. The help text for the module is still
accessible with `help modules <name>`.
Fixes#10499, #10311, #11609, #13470, #14033, and #14402.
Partially fixes#10707.
Does **not** fix#11447.
# User-Facing Changes
* Help text for commands can be obtained by running `help <command
name>`, where the command name is the same thing you would type in order
to execute the command. Previously, it was the name of the function as
written in the source file.
* For example, for the following module `spam` with command `meow`:
```nushell
module spam {
# help text
export def meow [] {}
}
```
* Before this PR:
* Regardless of how `meow` is `use`d, the help text is viewable by
running `help meow`.
* After this PR:
* When imported with `use spam`: The `meow` command is executed by
running `spam meow` and the `help` text is viewable by running `help
spam meow`.
* When imported with `use spam foo`: The `meow` command is executed by
running `meow` and the `help` text is viewable by running `meow`.
* When a module has a `main` command defined, `help <module name>` will
return help for the main command, rather than the module. To access the
help for the module, use `help modules <module name>`.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
N/A
# Description
Fixes#14401 where expressions passed to `timeit` will execute twice.
This PR removes the expression support for `timeit`, as this behavior is
almost exclusive to `timeit` and can hinder migration to the IR
evaluator in the future. Additionally, `timeit` used to be able to take
a `block` as an argument. Blocks should probably only be allowed for
parser keywords, so this PR changes `timeit` to instead only take
closures as an argument. This also fixes an issue where environment
updates inside the `timeit` block would affect the parent scope and all
commands later in the pipeline.
```nu
> timeit { $env.FOO = 'bar' }; print $env.FOO
bar
```
# User-Facing Changes
`timeit` now only takes a closure as the first argument.
# After Submitting
Update examples in the book/docs if necessary.
<!--
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 made the `cwd` parameter in the functions from the `table`
command not used when targeting `not(feature = "os)`. As without an OS
and therefore without filesystem we don't have any real concept of a
current working directory. This allows using the `table` command in the
WASM context.
# 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
> ```
-->
My tests timed out on the http stuff but I cannot think why this would
trigger a test failure. Let's see what the CI finds out.
# 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.
-->
Alternative solution to:
- #12195
The other approach:
- #14305
# Description
Adds ~`path const`~ `path self`, a parse-time only command for getting
the absolute path of the source file containing it, or any file relative
to the source file.
- Useful for any script or module that makes use of non nuscript files.
- Removes the need for `$env.CURRENT_FILE` and `$env.FILE_PWD`.
- Can be used in modules, sourced files or scripts.
# Examples
```nushell
# ~/.config/nushell/scripts/foo.nu
const paths = {
self: (path self),
dir: (path self .),
sibling: (path self sibling),
parent_dir: (path self ..),
cousin: (path self ../cousin),
}
export def main [] {
$paths
}
```
```nushell
> use foo.nu
> foo
╭────────────┬────────────────────────────────────────────╮
│ self │ /home/user/.config/nushell/scripts/foo.nu │
│ dir │ /home/user/.config/nushell/scripts │
│ sibling │ /home/user/.config/nushell/scripts/sibling │
│ parent_dir │ /home/user/.config/nushell │
│ cousin │ /home/user/.config/nushell/cousin │
╰────────────┴────────────────────────────────────────────╯
```
Trying to run in a non-const context
```nushell
> path self
Error: × this command can only run during parse-time
╭─[entry #1:1:1]
1 │ path self
· ─────┬────
· ╰── can't run after parse-time
╰────
help: try assigning this command's output to a const variable
```
Trying to run in the REPL i.e. not in a file
```nushell
> const foo = path self
Error: × Error: nu:🐚:file_not_found
│
│ × File not found
│ ╭─[entry #3:1:13]
│ 1 │ const foo = path self
│ · ─────┬────
│ · ╰── Couldn't find current file
│ ╰────
│
╭─[entry #3:1:13]
1 │ const foo = path self
· ─────┬────
· ╰── Encountered error during parse-time evaluation
╰────
```
# Comparison with #14305
## Pros
- Self contained implementation, does not require changes in the parser.
- More concise usage, especially with parent directories.
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
- fixes flakey tests from solving #14241
# Description
This is a preliminary fix for the flaky tests and also
shortened the `--max-time` in the tests.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
---------
Signed-off-by: Alex Kattathra Johnson <alex.kattathra.johnson@gmail.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
Fixes#14515
Also tweaks the fix from #11261 _just in case_ someone has a `foo`
executable
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
N/A
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# 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 https://github.com/nushell/nushell/issues/14487
This PR tries to allow the `select` to stream better by changing the for
loops that collected the output into a `Vec<Value>` prior to returning
it into a map that returns the data as it is processed.
One curiosity, `select` transforms the input into a `PipelineIterator`.
If I remove this code, it still passes all tests. I'm not sure all this
`PipelineIterator` code is even needed. I left it for someone to tell me
if it's necessary.
# 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.
-->
Makes the `glob` command stream
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
The glob command now streams
# 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.
-->
N/A
# Description
Better discoverability of `drop` subcommands
"I want to remove items by index" -> `drop nth`
h/t @amtoine
# User-Facing Changes
More search terms
This PR implements PWD-per-drive as described in discussion #14355
# Description
On Windows, CMD or PowerShell assigns each drive its own current
directory. For example, if you are in 'C:\Windows', switch to 'D:', and
navigate to 'D:\Game', you can return to 'C:\Windows' by simply typing
'C:'.
This PR enables Nushell on Windows to have the same capability, allowing
each drive to maintain its own PWD (Present Working Directory).
# User-Facing Changes
Currently, 'cd' or 'ls' only accept absolute paths if the path starts
with 'C:' or another drive letter. With PWD-per-drive, users can use
'cd' (or auto cd) and 'ls' in the same way as 'cd' and 'dir' in
PowerShell, or similarly to 'cd' and 'dir' in CMD (noting that cd in CMD
has slightly different behavior, 'cd' for another drive only changes
current directory of that drive, but does not switch there).
Interaction example on switching between drives:
```Nushell
~>D:
D:\>cd Test
D:\Test\>C:
~>D:
D:\Test\>C:
~>cd D:..
D:\>C:x/../y/../z/..
~>cd D:Test\Test
D:\Test\Test>C:
~>D:...
D:\>
```
Interaction example on auto-completion at cmd line:
```Nushell
~>cd D:\test[Enter]
D:\test>~[Enter]
~>D:[TAB]
~>D:\test[Enter]
D:\test>c:.c[TAB]
c:\users\nushell\.cargo\ c:\users\nushell\.config\
```
Interaction example on pass PWD-per-drive to child process: (Note CMD
will use it, but PowerShell will ignore it though it still prepares such
info for child process)
```Nushell
~>cd D:\Test
D:\Test>cd E:\Test
E:\Test\>~
~>CMD
Microsoft Windows [Version 10.0.22631.4460]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Nushell>d:
D:\Test>e:
E:\Test>
```
# Brief Change Description
1.Added 'crates/nu-path/src/pwd_per_drive.rs' to implement a 26-slot
array mapping drive letters to PWDs. Test cases are included in the same
file, along with a doctest for the usage of PWD-per-drive.
2. Modified 'crates/nu-path/src/lib.rs' to declare module of
pwd_per_drive and export struct for PWD-per-drive.
3. Modified 'crates/nu-protocol/src/engine/stack.rs' to sync PWD when
set_cwd() is called. Add PWD-per-drive map as member. Clone between
parent and child. Stub/proxy for nu_path::expand_path_with() to
facilitate filesystem commands using PWD-per-drive.
4. Modified 'crates/nu-cli/src/repl.rs' auto_cd uses PWD-per-drive to
expand path.
5. Modified 'crates/nu-cli/src/completions/completion_common.rs' to
expand relative path when press [TAB] at command line.
6. Modified 'crates/nu-engine/src/env.rs' to collect PWD-per-drive info
as env vars for child process as CMD or PowerShell do, this can let
child process inherit PWD-per-drive info.
7. Modified 'crates/nu-engine/src/eval.rs', caller clone callee's
PWD-per-drive info, supporting 'def --env'
8. Modified 'crates/nu-engine/src/eval_ir.rs', 'def --env' support.
Remove duplicated fn redirect_env()
9. Modified 'src/run.rs', to init PWD-per-drive when startup.
filesystem commands that modified:
1. Modified 'crates/nu-command/src/filesystem/cd.rs', 1 line change to
use stackscoped PWD-per-drive.
Other commands, commit pending....
Local test def --env OK:
```nushell
E:\study\nushell> def --env env_cd_demo [] {
::: cd ~
::: cd D:\Project
::: cd E:Crates
::: }
E:\study\nushell>
E:\study\nushell> def cd_no_demo [] {
::: cd ~
::: cd D:\Project
::: cd E:Crates
::: }
E:\study\nushell> cd_no_demo
E:\study\nushell> C:
C:\>D:
D:\>E:
E:\study\nushell>env_cd_demo
E:\study\nushell\crates> C:
~>D:
D:\Project>E:
E:\study\nushell\crates>
```
# Tests + Formatting
- `cargo fmt --all -- --check` passed.
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used`
passed.
- `cargo test --workspace` passed on Windows developer mode and Ubuntu.
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` passed.
- nushell:
```
> use toolkit.nu # or use an `env_change` hook to activate it automatically
> toolkit check pr
> ```
passed
---------
Co-authored-by: pegasus.cadence@gmail.com <pegasus.cadence@gmail.com>
# Description
I always wondered why the module env vars `CURRENT_FILE`, `FILE_PWD`,
`PROCESS_PATH` weren't available in the source command. I tried to add
them here. I think it could be helpful but I'm not sure. I'm also not
sure this hack is what we should do but I thought I'd put it out there
for fun.
Thoughts?
### Run Module (works as it did before)
```nushell
❯ open test_module.nu
def main [] {
print $"$env.CURRENT_FILE = ($env.CURRENT_FILE?)"
print $"$env.FILE_PWD = ($env.FILE_PWD?)"
print $"$env.PROCESS_PATH = ($env.PROCESS_PATH?)"
}
❯ nu test_module.nu
$env.CURRENT_FILE = /Users/fdncred/src/nushell/test_module.nu
$env.FILE_PWD = /Users/fdncred/src/nushell
$env.PROCESS_PATH = test_module.nu
```
### Use Module (works as it did before)
```nushell
❯ open test_module2.nu
export-env {
print $"$env.CURRENT_FILE = ($env.CURRENT_FILE?)"
print $"$env.FILE_PWD = ($env.FILE_PWD?)"
print $"$env.PROCESS_PATH = ($env.PROCESS_PATH?)"
}
❯ use test_module2.nu
$env.CURRENT_FILE = /Users/fdncred/src/nushell/test_module.nu
$env.FILE_PWD = /Users/fdncred/src/nushell
$env.PROCESS_PATH =
```
### Sourced non-module script (this is the new part)
> [!NOTE]
> Note: We intentionally left out PROCESS_PATH since it's supposed to
> to work like argv[0] in C, which is the name of the program being
executed.
> Since we're not executing a program, we don't need to set it.
```nushell
❯ open test_source.nu
print $"$env.CURRENT_FILE = ($env.CURRENT_FILE?)"
print $"$env.FILE_PWD = ($env.FILE_PWD?)"
print $"$env.PROCESS_PATH = ($env.PROCESS_PATH?)"
❯ source test_source.nu
$env.CURRENT_FILE = /Users/fdncred/src/nushell/test_source.nu
$env.FILE_PWD = /Users/fdncred/src/nushell
$env.PROCESS_PATH =
```
Also, what is PROCESS_PATH even supposed to be?
# 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
- Refactor code to be simpler.
- Make the mentioned changes.
- `scopeguard` is added as a direct dependency. Helps simplify the code.
Rather than roll an ad-hoc version of it myself, I thought it would be
better to use `scopeguard` as it was already an indirect dependency.
# User-Facing Changes
- Add `--beginning` flag, which is used to validate the response and
provide early errors in case of unexpected inputs.
- Both `terminator` and `beginning` sequences (when provided) are not
included in the command's output. Turns out they are almost always
removed from the output, and because they are known beforehand they can
be added back by the user.
# Description
Removes unnecessary usages of `Call::rest_iter_flattened` and
`get_rest_for_glob_pattern` and replaces them with `CallExt::rest`.
# User-Facing Changes
None
# Description
This PR enables some tests that were disabled on macos.
We shall see if the CI passes. (Update: CI has passed.)
# User-Facing Changes
Should be no user-facing changes as only a test-file is modified.
# Tests + Formatting
Test coverage should increase
Co-authored-by: Jasha <jsimpson@hiddenroad.com>
# Description
Fixes#14470 where the `sys cpu` command is slow. This was done by
removing the `cpu_usage` column from the default output, since it takes
400ms to calculate. Instead a `--long` flag was added that, when
provided, adds back the `cpu_usage` column.
```nu
# Before
> bench { sys cpu | length } | get mean
401ms 591µs 896ns
# After
> bench { sys cpu | length } | get mean
500µs 13ns # around 1-2ms in practice
```
# User-Facing Changes
- `sys cpu` no longer has a `cpu_usage` column by default.
- Added a `--long` flag for `sys cpu` to add back the removed column.
<!--
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>
# Description
Implements #11234 based on the comments there:
* (Previously implemented): `into record` handles nanoseconds (as well
as milliseconds and microseconds, which the deprecated commands didn't
support).
* Added deprecation warning to `date to-record` and `date to-table`
* Added new example for `into record` showing the conversion to a table
* Changed `std/dt` to use `into record`
* Added "Deprecated" category back to nu-protocol::Signature
* Assigned the deprecated commands to the Deprecated category so be
categorized properly in the online Doc.
# User-Facing Changes
Deprecated command warning
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
Searched doc for existing uses of `date to-record` and `date to-table`:
* For primary English-language docs, there are no uses other than in the
auto-generated command help, which will be updated based on this PR
* Other language translations appear to have an old use in several
places and will need to be updated to match the English-language doc.
# Description
While reviewing #14388, I think we can make some improvement on parser.
For the following code:
```nushell
let a = 3
a = 10 # should be error
$a = 10 # another error
```
I think they can raise `ParseError`, so nushell doesn't need to move
forward compiling IR block.
# User-Facing Changes
```nushell
let a = 3
a = 10
```
Will raise parse error instead of compile error.
# Tests + Formatting
Added 1 test.
# Description
Adds a new `Filesize` type so that `FromValue` can be used to convert a
`Value::Filesize` to a `Filesize`. Currently, to extract a filesize from
a `Value` using `FromValue`, you have to extract an `i64` which coerces
`Value::Int`, `Value::Duration`, and `Value::Filesize` to an `i64`.
Having a separate type also allows us to enforce checked math to catch
overflows. Similarly, it allows us to specify other trait
implementations like `Display` in a common place.
# User-Facing Changes
Multiplication with filesizes now error on overflow. Should not be a
breaking change for plugins (i.e., serialization) since `Filesize` is
marked with `serde(transparent)`.
# Tests + Formatting
Updated some tests.
# Description
Follow up to #14341. Changes the fields of `Hooks` to `Vec` or `Hashmap`
to match the new config defaults.
# User-Facing Changes
Mostly the same as #14341. `pre_prompt` and `pre_execution` must now be
a list, and `env_change` must be a record.
# Description
Before this PR, `length` did not check its input type at run-time, so it
would attempt to calculate a length for any input with indeterminate
type (e.g., `echo` which has an `any` output type). This PR makes
`length` only work on the types specifically supported in its
input/output types (list/table, binary, and nothing), making the
behavior the same at parse-time and at run-time.
Fixes#14462
# User-Facing Changes
Length will error if passed an unsupported type:
Before (only caught at parse-time):
```nushell
"hello" | length
Error: nu::parser::input_type_mismatch
× Command does not support string input.
╭─[entry #2:1:11]
1 │ "hello" | length
· ───┬──
· ╰── command doesn't support string input
╰────
echo "hello" | length
# => 1
```
After (caught at parse-time and run-time):
```nushell
"hello" | length
Error: nu::parser::input_type_mismatch
× Command does not support string input.
╭─[entry #22:1:11]
1 │ "hello" | length
· ───┬──
· ╰── command doesn't support string input
╰────
echo "hello" | length
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #23:1:6]
1 │ echo "hello" | length
· ───┬─── ───┬──
· │ ╰── only list, table, binary, and nothing input data is supported
· ╰── input type: string
╰────
```
# Description
When looking into #14395, I found that `unicode-width` from 0.1 to 0.2
contains a breaking change, the mainly change is it treats newlines as
width 1. So relative tests(str stats) are broken.
But I think it's ok to adjust the test.
# User-Facing Changes
The output of `str stats` might change if there are `\n` in the input.
### Before
```nushell
> "a\nb" | str stats | get unicode-width
2
```
### After
```nushell
> "a\nb" | str stats | get unicode-width
3
```
# Tests + Formatting
Adjusted 2 tests.
# After Submitting
NaN
# Description
Propagate existing errors in the pipeline, rather than a type error.
# User-Facing Changes
Nothing that previously worked should be affected, this should just
change the errors.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# 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
# Description
List values and list streams have the same type (`list<>`). Rather,
streaming is a separate property of the pipeline/command output. This PR
removes the unnecessary `ListStream` type.
# User-Facing Changes
Should be none, except `random dice` now has a more specific output
type.
## Related
- #10150
- https://github.com/nushell/nushell/pull/10150#issuecomment-1721238336
- #10387
- https://github.com/nushell/nushell/pull/10387#issuecomment-1722228185
# Description
`term query`: a command for querying information from the terminal.
Prints the `$query`, and immediately starts reading raw bytes from
stdin.
The standard input will be read until the `terminator` sequence is
encountered.
The `terminator` is not removed from the output.
It also stops on <kbd>Ctrl-C</kbd> with an error.
```
Usage:
> term query {flags} <query>
Flags:
-h, --help: Display the help message for this command
-t, --terminator (required parameter) <one_of(binary, string)>: stdin will be read until this sequence is encountered
Parameters:
query <one_of(binary, string)>: The query that will be printed to stdout
```
This was previously possible with `input` until #10150.
`input` command's features such as cursor control, deleting input etc.
are useful, but interfere with this use case.
`term query` makes the following uses possible:
```nushell
# get the terminal size with ansi escape codes
def terminal-size [] {
let response = term query (ansi size) --terminator 'R'
# $response should look like this
# Length: 9 (0x9) bytes | printable whitespace ascii_other non_ascii
# 00000000: 1b 5b 33 38 3b 31 35 30 52 •[38;150R
let sz = $response | bytes at 2..<-1 | decode
# 38;150
# $sz should look like 38;150
let size = ($sz | split row ';' | each {into int})
# output in record syntax
{
rows: $size.0
columns: $size.1
}
}
```
```nushell
# read clipboard content using OSC 52
term query $"(ansi --osc '52;c;?')(ansi st)" --terminator (ansi st)
| bytes at 7..<-2
| decode
| decode base64
| decode
```
# User-Facing Changes
- added `ansi query`
# Tests + Formatting
- Integration tests should be added if possible.
# Description
The "append" operator currently serves as both the append operator and
the concatenation operator. This dual role creates ambiguity when
operating on nested lists.
```nu
[1 2] ++ 3 # appends a value to a list [1 2 3]
[1 2] ++ [3 4] # concatenates two lists [1 2 3 4]
[[1 2] [3 4]] ++ [5 6]
# does this give [[1 2] [3 4] [5 6]]
# or [[1 2] [3 4] 5 6]
```
Another problem is that `++=` can change the type of a variable:
```nu
mut str = 'hello '
$str ++= ['world']
($str | describe) == list<string>
```
Note that appending is only relevant for lists, but concatenation is
relevant for lists, strings, and binary values. Additionally, appending
can be expressed in terms of concatenation (see example below). So, this
PR changes the `++` operator to only perform concatenation.
# User-Facing Changes
Using the `++` operator with a list and a non-list value will now be a
compile time or runtime error.
```nu
mut list = []
$list ++= 1 # error
```
Instead, concatenate a list with one element:
```nu
$list ++= [1]
```
Or use `append`:
```nu
$list = $list | append 1
```
# After Submitting
Update book and docs.
---------
Co-authored-by: Douglas <32344964+NotTheDr01ds@users.noreply.github.com>
# Description
This PR removes the `terminal_size` crate everywhere that it made sense.
I replaced it with crossterm's version called `size`. The places I
didn't remove it were the places that did not have a dependency on
crossterm. So, I thought it was "cheaper" to have a dep on term_size vs
crossterm in those locations.
# Description
Apparently it should be joint CRLF for the EOL marker
https://www.rfc-editor.org/rfc/rfc2616#section-2.2
Plain LF isn't particularly standardized and many backends don't
recognize it. Tested on `starlette`
# User-Facing Changes
None
# Tests + Formatting
It's two characters; everything passes
# After Submitting
Not needed
- fixes#14398
I will properly fill out this PR and fix any tests that might break when
I have the time, this was a quick fix.
# Description
This PR makes `from csv` and `from tsv`, with the `--flexible` flag,
stop dropping extra/unexpected columns.
# User-Facing Changes
`$text`'s contents
```csv
value
1,aaa
2,bbb
3
4,ddd
5,eee,extra
```
Old behavior
```nushell
> $text | from csv --flexible --noheaders
╭─#─┬─column0─╮
│ 0 │ value │
│ 1 │ 1 │
│ 2 │ 2 │
│ 3 │ 3 │
│ 4 │ 4 │
│ 5 │ 5 │
╰─#─┴─column0─╯
```
New behavior
```nushell
> $text | from csv --flexible --noheaders
╭─#─┬─column0─┬─column1─┬─column2─╮
│ 0 │ value │ ❎ │ ❎ │
│ 1 │ 1 │ aaa │ ❎ │
│ 2 │ 2 │ bbb │ ❎ │
│ 3 │ 3 │ ❎ │ ❎ │
│ 4 │ 4 │ ddd │ ❎ │
│ 5 │ 5 │ eee │ extra │
╰─#─┴─column0─┴─column1─┴─column2─╯
```
- The first line in a csv (or tsv) document no longer limits the number
of columns
- Missing values in columns are longer automatically filled with `null`
with this change, as a later row can introduce new columns. **BREAKING
CHANGE**
Because missing columns are different from empty columns, operations on
possibly missing columns will have to use optional access syntax e.g.
`get foo` => `get foo?`
# Tests + Formatting
Added examples that run as tests and adjusted existing tests to confirm
the new behavior.
# After Submitting
Update the workaround with fish completer mentioned
[here](https://www.nushell.sh/cookbook/external_completers.html#fish-completer)