This change introduces new `search_result` style supported in the color
config. The change also removes obsolete check for `config.ls_colors`
for computing the style. `config.ls_colors` has been removed last year,
so this removes the reference to the obsolete flag, along with a cleanup
that removes all the code that used to rely on ls_colors for
highlighting search results.
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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
Fixes: #9165
It's because `sys` returns a lazy record, and `insert`, `update`,
`upsert` can't operate on lazy record yet.
# User-Facing 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the
standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
I don't want to rm my home again.. sadly..
# 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.
-->
check if there is unique argument
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
user will not easily rm their home
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the
standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
# Description
Fixes#9254.
# User-Facing Changes
upserting data of a cellpath that doesn't exist into a record now
creates the cellpath.
# Tests + Formatting
```
~/CodingProjects/nushell> mut a = {}
~/CodingProjects/nushell> $a.b.c = 99
~/CodingProjects/nushell> $a
╭───┬────────────╮
│ │ ╭───┬────╮ │
│ b │ │ c │ 99 │ │
│ │ ╰───┴────╯ │
╰───┴────────────╯
```
<!--
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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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: #7853
I found that I want this feature too...
So I take over it, sorry for that @VincenzoCarlino
# User-Facing 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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
<!--
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.
-->
Cleans up various tests that unnecessarily use the `cwd` argument of
`nu!`, and the `pipeline` function for single line commands. Also
replaces some unnecessary raw strings with normal strings. Part of
#8670.
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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
> ```
-->
All checks pass
# 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.
-->
Closes#9003.
This PR changes `group-by` so that its optional argument is interpreted
as a cell path. In turn, this lets users use `?` to ignore rows that are
missing the column they wish to group on. For example:
```
> [{foo: 123}, {foo: 234}, {bar: 345}] | group-by foo
Error: nu:🐚:column_not_found
× Cannot find column
╭─[entry #3:1:1]
1 │ [{foo: 123}, {foo: 234}, {bar: 345}] | group-by foo
· ─────┬──── ─┬─
· │ ╰── cannot find column 'foo'
· ╰── value originates here
╰────
> [{foo: 123}, {foo: 234}, {bar: 345}] | group-by foo?
╭─────┬───────────────╮
│ 123 │ [table 1 row] │
│ 234 │ [table 1 row] │
╰─────┴───────────────╯
```
~~This removes the ability to pass `group-by` a closure or block (I
wasn't able to figure out how to make the 2 features coexist), and so it
is a breaking change. I think this is OK; I didn't even know `group-by`
could accept a closure or block because there was no example for that
functionality.~~
# Description
Fixes: #8565
Here is another pr #7240 tried to address the issue, but it works in a
wrong way.
After this change `o+e>` won't redirect all stdout message then stderr
message and it works more like how bash does.
# User-Facing Changes
For the given python code:
```python
# test.py
import sys
print('aa'*300, flush=True)
print('bb'*999999, file=sys.stderr, flush=True)
print('cc'*300, flush=True)
```
Running `python test.py out+err> a.txt` shoudn't hang nushell, and
`a.txt` keeps output in the same order
## About the change
The core idea is that when doing lite-parsing, introduce a new variant
`LiteElement::SameTargetRedirection` if we meet `out+err>` redirection
token(which is generated by lex function),
During converting from lite block to block,
LiteElement::SameTargetRedirection will be converted to
PipelineElement::SameTargetRedirection.
Then in the block eval process, if we get
PipelineElement::SameTargetRedirection, we'll invoke `run-external` with
`--redirect-combine` flag, then pipe the result into save command
## What happened internally?
Take the following command as example:
`^ls o+e> log.txt`
lex parsing result(`Tokens`) are not changed, but `LiteBlock` and
`Block` is changed after this pr.
### LiteBlock before
```rust
LiteBlock {
block: [
LitePipeline { commands: [
Command(None, LiteCommand { comments: [], parts: [Span { start: 39041, end: 39044 }] }),
// actually the span of first Redirection is wrong too..
Redirection(Span { start: 39058, end: 39062 }, StdoutAndStderr, LiteCommand { comments: [], parts: [Span { start: 39050, end: 39057 }] }),
]
}]
}
```
### LiteBlock after
```rust
LiteBlock {
block: [
LitePipeline {
commands: [
SameTargetRedirection {
cmd: (None, LiteCommand { comments: [], parts: [Span { start: 147945, end: 147948}]}),
redirection: (Span { start: 147949, end: 147957 }, LiteCommand { comments: [], parts: [Span { start: 147958, end: 147965 }]})
}
]
}
]
}
```
### Block before
```rust
Pipeline {
elements: [
Expression(None, Expression {
expr: ExternalCall(Expression { expr: String("ls"), span: Span { start: 39042, end: 39044 }, ty: String, custom_completion: None }, [], false),
span: Span { start: 39041, end: 39044 },
ty: Any, custom_completion: None
}),
Redirection(Span { start: 39058, end: 39062 }, StdoutAndStderr, Expression { expr: String("out.txt"), span: Span { start: 39050, end: 39057 }, ty: String, custom_completion: None })] }
```
### Block after
```rust
Pipeline {
elements: [
SameTargetRedirection {
cmd: (None, Expression {
expr: ExternalCall(Expression { expr: String("ls"), span: Span { start: 147946, end: 147948 }, ty: String, custom_completion: None}, [], false),
span: Span { start: 147945, end: 147948},
ty: Any, custom_completion: None
}),
redirection: (Span { start: 147949, end: 147957}, Expression {expr: String("log.txt"), span: Span { start: 147958, end: 147965 },ty: String,custom_completion: 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-utils/standard_library/tests.nu` 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.
Related to #8368.
# Description
as planned in #8311, the `enter`, `shells`, `g`, `n` and `p` commands
have been re-implemented in pure-`nushell` in the standard library.
this PR removes the `rust` implementations of these commands.
- all the "shells" tests have been removed from
`crates/nu-commnand/tests/commands/` in
2cc6a82da6, except for the `exit` command
- `cd` does not use the `shells` feature in its source code anymore =>
that does not change its single-shell behaviour
- all the command implementations have been removed from
`crates/nu-command/src/shells/`, except for `exit.rs` => `mod.rs` has
been modified accordingly
- the `exit` command now does not compute any "shell" related things
- the `--now` option has been removed from `exit`, as it does not serve
any purpose without sub-shells
# User-Facing Changes
users may now not use `enter`, `shells`, `g`, `n` and `p`
now they would have to use the standard library to have access to
equivalent features, thanks to the `dirs.nu` module introduced by @bobhy
in #8368
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
the website will have to be regenerated to reflect the removed commands
👍
# Description
closes#8934
this pr improves the diagnostic emitted when the name and parameters of
either `def`, `def-env` or `extern` are not separated by a space
```nu
Error:
× no space between name and parameters
╭─[entry #1:1:1]
1 │ def err[] {}
· ▲
· ╰── expected space
╰────
help: consider adding a space between the `def` command's name and its parameters
```
from
```nu
Error: nu::parser::missing_positional
× Missing required positional argument.
╭─[entry #1:1:1]
1 │ def err[] {}
╰────
help: Usage: def <def_name> <params> <body>
```
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
Co-authored-by: Jelle Besseling <jelle@pingiun.com>
# Description
This PR fixes issue #9043 where find -v was returning empty tables
and/or wrong output.
It also refactors some big code chunks with repetitions into it's own
functions.
# User-Facing Changes
# Tests + Formatting
Unit tests added for asserting changes.
# After Submitting
# Description
Before this PR, `math round` ignores the input if it's an `int`. This
results in the following behaviour:
```
> 123 | math round --precision -1
123
```
When the correct result is 120.
Now `int values` are converted to `float values` before actually
rounding up the number in order to take advantage of the float
implementation.
Fixes#9049.
# Description
Add option that combines both output streams to the `run-external`
command.
This allows you to do something like this:
```nushell
let res = do -i { run-external --redirect-combine <command that prints to stdout and stderr> } | complete
if $res.exit_code != 0 {
# Only print output when command has failed.
print "The command has failed, these are the logs:"
print $res.stdout
}
```
# User-Facing Changes
No breaking changes, just an extra option.
# Tests + Formatting
Added a test that checks the new option
# 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: Jelle Besseling <jelle@bigbridge.nl>
This PR just tidies up some tests by removing unused code:
1. If the filesystem is not touched, don't use the filesystem
playground/sandbox
2. If the filesystem is not touched, don't specify the `cwd`
3. If the command is short, don't bother wrapping it in `pipeline()`
4. If the command doesn't have quotes, don't bother with a `r#"..."#`
raw string
Part of #8670.
# Description
Extends the `extern` syntax to allow commands that accept raw arguments.
This is mainly added to allow wrapper type scripts for external
commands.
This is an example on how this can be used:
```nushell
extern foo [...rest] {
print ($rest | str join ',' )
}
foo --bar baz -- -q -u -x
# => --bar,baz,--,-q,-u,-x
```
(It's only possible to accept a single ...varargs argument in the
signature)
# User-Facing Changes
No breaking changes, just extra possibilities.
# Tests + Formatting
Added a test for this new behaviour and ran the toolkit pr checker
# After Submitting
This is advanced functionality but it should be documented, I will open
a new PR on the book for that
Co-authored-by: Jelle Besseling <jelle@bigbridge.nl>
# Description
Previously, `par-each` acted like a `flatmap`: first mapping the data,
then applying a `flatten`. This is unlike `each`, which just maps the
data. Now `par-each` works like `each` in this regard, leaving nested
data unflattened.
Fixes#8497
# User-Facing Changes
Previously:
`[1 2 3] | par-each {|e| [$e, $e] }` --> `[1,1,2,2,3,3]`
Now:
`[1 2 3] | par-each {|e| [$e, $e] }` --> `[[1,1],[2,2],[3,3]]`
# Tests
This adds one test that verifies the lack of flattening for `par-each`.
close? #8060
Quite a bit of refactoring took place.
I believe a few improvements to collapse/expand were made.
I've tried to track any performance regressions and seems like it is
fine.
I've noticed something different now with default configuration path or
something in this regard?
So I might missed something while testing because of this.
Requires some oversight.
---------
Signed-off-by: Maxim Zhiburt <zhiburt@gmail.com>
# Description
this pr condenses `MutBuiltinVar`, `LetBuiltinVar` and `ConstBuiltinVar`
into one error:
```nu
Error: nu::parser::name_is_builtin_var
× `in` used as variable name.
╭─[entry #69:1:1]
1 │ let in = 420
· ─┬
· ╰── already a builtin variable
╰────
help: 'in' is the name of a builtin Nushell variable and cannot be used
as a variable name
```
it also fixes this case which was previously not handled
```nu
let $nu = 420 # this variable would have been 'lost'
```
# Description
This effectively reverts #8635. We shipped this change with 0.78 and
received many comments/issues related to this restriction feeling like a
step backward.
fixes: #8844
(and probably other issues)
# User-Facing Changes
Returns numbers and number-like values to being allowed to be bare
words. Examples: `3*`, `1fb43`, `4,5`, and related.
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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
Verified on discord with maintainer
Change adds regex separators in split rows/column/list. The primary
motivating reason was to make it easier to split on separators with
unbounded whitespace without requiring a lot of trim jiggery. But,
secondary motivation is the same as the set of all motivations for
adding split regex features to most languages.
# User-Facing Changes
Adds -r option to split rows/column/list.
# Tests + Formatting
Ran tests, however tests.nu fails with unrelated errors:
```
~/src/nushell> cargo run -- crates/nu-utils/standard_library/tests.nu 04/02/2023 02:07:25 AM
Finished dev [unoptimized + debuginfo] target(s) in 0.24s
Running `target/debug/nu crates/nu-utils/standard_library/tests.nu`
INF|2023-04-02T02:07:27.060|Running tests in test_asserts
INF|2023-04-02T02:07:27.141|Running tests in test_dirs
Error:
× list is just pwd after initialization
INF|2023-04-02T02:07:27.167|Running tests in test_logger
INF|2023-04-02T02:07:27.286|Running tests in test_std
Error:
× some tests did not pass (see complete errors above):
│
│ test_asserts test_assert
│ test_asserts test_assert_equal
│ test_asserts test_assert_error
│ test_asserts test_assert_greater
│ test_asserts test_assert_greater_or_equal
│ test_asserts test_assert_length
│ test_asserts test_assert_less
│ test_asserts test_assert_less_or_equal
│ test_asserts test_assert_not_equal
│ ⨯ test_dirs test_dirs_command
│ test_logger test_critical
│ test_logger test_debug
│ test_logger test_error
│ test_logger test_info
│ test_logger test_warning
│ test_std test_path_add
│
```
Upon investigating seeing this difference:
```
╭───┬─────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ 0 │ /var/folders/1f/ltbr1m8s5s1811k6n1rhpc0r0000gn/T/test_dirs_c1ed89d6-19f7-47c7-9e1f-74c39f3623b5 │
│ 1 │ /private/var/folders/1f/ltbr1m8s5s1811k6n1rhpc0r0000gn/T/test_dirs_c1ed89d6-19f7-47c7-9e1f-74c39f3623b5 │
╰───┴─────────────────────────────────────────────────────────────────────────────────────────────────────────╯
```
This seems unrelated to my changes, but can investigate further if
desired.
# 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: Robert Waugh <robert@waugh.io>
# Description
This PR aims to cover the tests under nu-command as part of this issue
#8670 to clean up any unnecessary wrapping funcs like `cwd(".")` or
`pipeline()`, etc.
This PR is still WIP and opening as draft to get first impressions and
feedback on a few tests before I go on changing more.
# User-Facing Changes
None
# Tests + Formatting
None
# After Submitting
None
---------
Signed-off-by: Harshal Chaudhari <harshal.chaudhary@gmail.com>
Co-authored-by: Reilly Wood <reilly.wood@icloud.com>
# Description
Prevents redefining fields in a record, for example `{a: 1, a: 2}` would
now error.
fixes https://github.com/nushell/nushell/issues/8699
# User-Facing Changes
Is technically a breaking change. If you relied on this behaviour to
give you the last value, your code will now error.
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-utils/standard_library/tests.nu` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
This PR makes `?` work with `reject`. For example:
```bash
> {} | reject foo
Error: nu:🐚:column_not_found
× Cannot find column
╭─[entry #2:1:1]
1 │ {} | reject foo
· ───┬── ─┬─
· │ ╰── cannot find column 'foo'
· ╰── value originates here
╰────
> {} | reject foo?
╭──────────────╮
│ empty record │
╰──────────────╯
```
This was prompted by [a user
question](https://discord.com/channels/601130461678272522/614593951969574961/1091466428546306078).
I would like to get this in for 0.78, I think it's low-risk and I want
the `?` feature to be as polished as possible for its debut.
# Description
Adds two more patterns when working with lists:
```
[1, ..$remainder]
```
and
```
[1, ..]
```
The first one collects the remaining items and assigns them into the
variable. The second one ignores any remaining values.
# User-Facing Changes
Adds more capability to list pattern matching.
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-utils/standard_library/tests.nu` 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
Currently, all four of these commands return a (rather-confusing)
spanless error when passed an empty list:
```
> [] | sort
Error:
× no values to work with
help: no values to work with
```
This PR changes these commands to always output `[]` if the input is
`[]`.
```
> [] | sort
╭────────────╮
│ empty list │
╰────────────╯
> [] | uniq-by foo
╭────────────╮
│ empty list │
╰────────────╯
```
I'm not sure what the original logic was here, but in the case of `sort`
and `uniq`, I think the current behavior is straightforwardly wrong.
`sort-by` and `uniq-by` are a bit more complicated, since they currently
try to perform some validation that the specified column name is present
in the input (see #8667 for problems with this validation, where a
possible outcome is removing the validation entirely). When passed `[]`,
it's not possible to do any validation because there are no records.
This opens up the possibility for situations like the following:
```
> [[foo]; [5] [6]] | where foo < 3 | sort-by bar
╭────────────╮
│ empty list │
╰────────────╯
```
I think there's a strong argument that `[]` is the best output for these
commands as well, since it makes pipelines like `$table | filter
$condition | sort-by $column` more predictable. Currently, this pipeline
will throw an error if `filter` evaluates to `[]`, but work fine
otherwise. This makes it difficult to write reliable code, especially
since users are not likely to encounter the `filter -> []` case in
testing (issue #5957). The only workaround is to insert manual checks
for an empty result. IMO, this is significantly worse than the "you can
typo a column name without getting an error" problem shown above.
Other commands that take column arguments (`get`, `select`, `rename`,
etc) already have `[] -> []`, so there's existing precedent for this
behavior.
The core question here is "what columns does `[]` have"? The current
behavior of `sort-by` is "no columns", while the current behavior of
`select` is "all possible columns". Both answers lead to accepting some
likely-buggy code without throwing on error, but in order to do better
here we would need something like `Value::Table` that tracks columns on
empty tables.
If other people disagree with this logic, I'm happy to split out the
`sort-by` and `uniq-by` changes into another PR.
# User-Facing Changes
`sort`, `uniq`, `sort-by`, and `uniq-by` now return `[]` instead of
throwing an error when input is `[]`.
# 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.
The existing behavior was not documented, and the new behavior is what
you would expect by default, so I don't think we need to update
documentation.
---------
Co-authored-by: Reilly Wood <reilly.wood@icloud.com>
This PR fixes a bug introduced in
https://github.com/nushell/nushell/pull/8571.
We were accidentally converting a `Result<Value, ShellError>` to JSON
instead of converting a `Value`. The upshot was that we were sending
JSON like `{"Ok":{"foo":"bar"}}` instead of `{"foo":"bar"}`.
This was an easy bug to miss, because `ureq::send_json()` accepts any
`impl serde::Serialize`. I've added a test to prevent regression.
# Description
This removes all the old style of quasi-ranges before we had full range
support from `str substring`. Functionality should otherwise work, but
only with the official range syntax.
# User-Facing Changes
Removes the array and string forms of ranges from `str substring`.
Leaves only the official range support for range values.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
This PR fixes `select` when given an empty list; it used to return
`null` when given an empty list. I also cleaned up other `select` tests
while I was in the area.
### Before:
```
> [] | select a | to nuon
null
```
### After:
```
> [] | select a | to nuon
[]
```
It looks like the previous behaviour was accidentally introduced by
[this PR](https://github.com/nushell/nushell/pull/7639).
# Description
Require that any value that looks like it might be a number (starts with
a digit, or a '-' + digit, or a '+' + digits, or a special form float
like `-inf`, `inf`, or `NaN`) must now be treated as a number-like
value. Number-like syntax can only parse into number-like values.
Number-like values include: durations, ints, floats, ranges, filesizes,
binary data, etc.
# User-Facing Changes
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
BREAKING CHANGE
Just making sure we see this for release notes 😅
This breaks any and all numberlike values that were treated as strings
before. Example, we used to allow `3,` as a bare word. Anything like
this would now require quotes or backticks to be treated as a string or
bare word, respectively.
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
> **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
Adds `|` patterns to `match`, allowing you to try multiple patterns for
the same case.
Example:
```
match {b: 1} { {a: $b} | {b: $b} => { print $b } }
```
Variables that don't bind are set to `$nothing` so that they can be
later checked.
This PR also:
fixes#8631
Creates a set of integration tests for pattern matching also
# User-Facing Changes
Adds `|` to `match`. Fixes variable binding scope.
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
> **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
Fixes: #8542
# User-Facing Changes
## Previous
```
❯ cat `~/TE ST/bug`
cat: ~/TE ST/bug: No such file or directory
```
## After
```
❯ cat `~/TE ST/bug`
a
```
This should be ok because We treat back-quoted strings as bare words
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
> **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 removes autoprinting the final value of a loop, much in the same
spirit as not autoprinting values at the end of statements. As we fix
these corner cases, it becomes more consistent that to print to the
screen in a script, you use the `print` command.
This gives a noticeable performance improvement as a bonus.
Before:
```
C:\Source\nushell〉 for x in 1..10 { $x }
1
2
3
4
5
6
7
8
9
10
```
Now:
```
C:\Source\nushell〉 for x in 1..10 { $x }
C:\Source\nushell〉
```
# User-Facing Changes
**BREAKING CHANGE**
Loops like `for`, `loop`, and `while` will no longer automatically print
loop values to the screen.
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
> **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.
Prior to this PR, the less/greater than operators (`<`, `>`, `<=`, `>=`)
would throw an error if either side was null. After this PR, these
operators return null if either side (or both) is null.
### Examples
```bash
1 < 3 # true
1 < null # null
null < 3 # null
null < null # null
```
### Motivation
JT [asked the C#
folks](https://discord.com/channels/601130461678272522/615329862395101194/1086137515053957140)
and this is apparently the approach they would choose for comparison
operators if they could start from scratch.
This PR makes `where` more convenient to use on jagged/missing data. For
example, we can now filter on columns that may not be present in every
row:
```
> [{foo: 123} {}] | where foo? > 10
╭───┬─────╮
│ # │ foo │
├───┼─────┤
│ 0 │ 123 │
╰───┴─────╯
```
this pr refines #8270 and closes#8109
# description
examples:
the original syntax is okay
```nu
def okay [nums: list] {} # the type of list will be list<any>
```
empty annotations are allowed in any variation
the last two may be caught by a future formatter,
but do not affect `nu` code currently
```nu
def okay [nums: list<>] {} # okay
def okay [nums: list< >] {} # weird but also okay
def okay [nums: list<
>] {} # also weird but okay
```
types are allowed (See [notes](#notes) below)
```nu
def okay [nums: list<int>] {} # `test [a b c]` will throw an error
def okay [nums: list< int > {} # any amount of space within the angle brackets is okay
def err [nums: list <int>] {} # this is not okay, `nums` and `<int>` will be parsed as
# two separate params,
```
nested annotations are allowed in many variations
```nu
def okay [items: list<list<int>>] {}
def okay [items: list<list>] {}
```
any unterminated annotation is caught
```nu
Error: nu::parser::unexpected_eof
× Unexpected end of code.
╭─[source:1:1]
1 │ def err [nums: list<int] {}
· ▲
· ╰── expected closing >
╰────
```
unknown types are flagged
```nu
Error: nu::parser::unknown_type
× Unknown type.
╭─[source:1:1]
1 │ def err [nums: list<str>] {}
· ─┬─
· ╰── unknown type
╰────
Error: nu::parser::unknown_type
× Unknown type.
╭─[source:1:1]
1 │ def err [nums: list<int, string>] {}
· ─────┬─────
· ╰── unknown type
╰────
```
# notes
the error message for mismatched types in not as intuitive
```nu
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[source:1:1]
1 │ def err [nums: list<int>] {}; err [a b c]
· ┬
· ╰── expected int
╰────
```
it should be something like this
```nu
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[source:1:1]
1 │ def err [nums: list<int>] {}; err [a b c]
· ──┬──
· ╰── expected list<int>
╰────
```
this is currently not implemented
# Description
This is an experiment to see what switching the `let/let-env` family to
math expressions for initialisers would be like.
# User-Facing Changes
This would require any commands you call from `let x = <command here>`
(and similar family) to call the command in parentheses. `let x = (foo)`
to call `foo`.
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
> **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.
