Closed
Conversation
Bumps [nu-ansi-term](https://github.com/nushell/nu-ansi-term) from 0.47.0 to 0.48.0. - [Release notes](https://github.com/nushell/nu-ansi-term/releases) - [Changelog](https://github.com/nushell/nu-ansi-term/blob/main/CHANGELOG.md) - [Commits](nushell/nu-ansi-term@v0.47.0...v0.48.0) --- updated-dependencies: - dependency-name: nu-ansi-term dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
hustcer
pushed a commit
that referenced
this pull request
Dec 17, 2023
# Description This pr allow us to use `filesize` type as a valid limit value, which is benefit for some file size based limits. # User-Facing Changes ```console /data/source/nushell> ulimit -f ╭───┬─────────────────────────────────────────────────────┬───────────┬───────────╮ │ # │ description │ soft │ hard │ ├───┼─────────────────────────────────────────────────────┼───────────┼───────────┤ │ 0 │ Maximum size of files created by the shell (kB, -f) │ unlimited │ unlimited │ ╰───┴─────────────────────────────────────────────────────┴───────────┴───────────╯ /data/source/nushell> ulimit -f 10Mib /data/source/nushell> ulimit -f ╭───┬─────────────────────────────────────────────────────┬───────┬───────╮ │ # │ description │ soft │ hard │ ├───┼─────────────────────────────────────────────────────┼───────┼───────┤ │ 0 │ Maximum size of files created by the shell (kB, -f) │ 10240 │ 10240 │ ╰───┴─────────────────────────────────────────────────────┴───────┴───────╯ /data/source/nushell> ulimit -n ╭───┬──────────────────────────────────────────────┬──────┬────────╮ │ # │ description │ soft │ hard │ ├───┼──────────────────────────────────────────────┼──────┼────────┤ │ 0 │ Maximum number of open file descriptors (-n) │ 1024 │ 524288 │ ╰───┴──────────────────────────────────────────────┴──────┴────────╯ /data/source/nushell> ulimit -n 10Mib Error: nu::shell::type_mismatch × Type mismatch. ╭─[entry #5:1:1] 1 │ ulimit -n 10Mib · ─┬─ · ╰── filesize is not compatible with resource RLIMIT_NOFILE ╰──── ``` # Tests + Formatting Make sure you've run and fixed any issues with these commands: - [x] add `commands::ulimit::limit_set_filesize1` - [x] add `commands::ulimit::limit_set_filesize2` - [x] `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - [x] `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)) - [x] `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library
hustcer
pushed a commit
that referenced
this pull request
Dec 25, 2023
…me (#11384) # Description Fixes #11382 # User-Facing Changes * before ```console nushell/test (109f629) [✘?] ❯ open hello.md hello nushell/test (109f629) [✘?] ❯ ls hello.md | get size ╭───┬─────╮ │ 0 │ 6 B │ ╰───┴─────╯ nushell/test (109f629) [✘?] ❯ open --raw hello.md | prepend "world" | save --raw --force hello.md ^C nushell/test (109f629) [✘?] ❯ ls hello.md | get size ╭───┬─────────╮ │ 0 │ 2.8 GiB │ ╰───┴─────────╯ ``` * after ```console nushell/test on fix_save [✘!?⇡] ❯ open hello.md | prepend "hello" | save --force hello.md nushell/test on fix_save [✘!?⇡] ❯ open --raw hello.md | prepend "hello" | save --raw --force ../test/hello.md Error: × pipeline input and output are same file ╭─[entry #4:1:1] 1 │ open --raw hello.md | prepend "hello" | save --raw --force ../test/hello.md · ────────┬─────── · ╰── can't save output to '/data/source/nushell/test/hello.md' while it's being reading ╰──── help: you should change output path nushell/test on fix_save [✘!?⇡] ❯ open hello | prepend "hello" | save --force hello Error: × pipeline input and output are same file ╭─[entry #5:1:1] 1 │ open hello | prepend "hello" | save --force hello · ──┬── · ╰── can't save output to '/data/source/nushell/test/hello' while it's being reading ╰──── help: you should change output path ``` # Tests + Formatting Make sure you've run and fixed any issues with these commands: - [x] add `commands::save::save_same_file_with_extension` - [x] add `commands::save::save_same_file_without_extension` - [x] `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - [x] `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)) - [x] `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library # After Submitting
hustcer
pushed a commit
that referenced
this pull request
Jun 30, 2024
Recommend holding until after #13125 is fully digested and *possibly*
until 0.96.
# Description
Fixes one of the issues described in #13125
The `do` signature included a `SyntaxShape:Any` as one of the possible
first-positional types. This is incorrect. `do` only takes a closure as
a positional. This had the result of:
1. Moving what should have been a parser error to evaluation-time
## Before
```nu
> do 1
Error: nu::shell::cant_convert
× Can't convert to Closure.
╭─[entry #26:1:4]
1 │ do 1
· ┬
· ╰── can't convert int to Closure
╰────
```
## After
```nu
> do 1
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry #5:1:4]
1 │ do 1
· ┬
· ╰── expected block, closure or record
╰────
```
2. Masking a bad test in `std assert`
This is a bit convoluted, but `std assert` tests included testing
`assert error` to make sure it:
* Asserts on bad code
* Doesn't assert on good code
The good-code test was broken, and was essentially bad-code (really
bad-code) that wasn't getting caught due to the bad signature.
Fixing this resulted in *parse time* failures on every call to
`test_asserts` (not something that particular test was designed to
handle.
This PR also fixes the test case to properly evaluate `std assert error`
against a good code path.
# User-Facing Changes
* Error-type returned (possible breaking change?)
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
# After Submitting
N/A
hustcer
pushed a commit
that referenced
this pull request
Jul 6, 2024
# Description closes #13298 so that duration mod duration / duration = duration ### Before ```nushell (92sec mod 1min) / 1sec Error: nu::parser::unsupported_operation × division is not supported between float and duration. ╭─[entry #5:1:1] 1 │ (92sec mod 1min) / 1sec · ────────┬─────── ┬ ──┬─ · │ │ ╰── duration · │ ╰── doesn't support these values · ╰── float ╰──── ``` ### After ```nushell ❯ (92sec mod 1min) / 1sec 32 ``` # 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. -->
hustcer
pushed a commit
that referenced
this pull request
Jul 20, 2024
…ure can have default parameters (#13393)
# Description
Close: #12083
Close: #12084
# User-Facing Changes
It's a breaking change because we have switched the position of
`<initial>` and `<closure>`, after the change, initial value will be
optional. So it's possible to do something like this:
```nushell
> let f = {|fib = [0, 1]| {out: $fib.0, next: [$fib.1, ($fib.0 + $fib.1)]} }
> generate $f | first 5
╭───┬───╮
│ 0 │ 0 │
│ 1 │ 1 │
│ 2 │ 1 │
│ 3 │ 2 │
│ 4 │ 3 │
╰───┴───╯
```
It will also raise error if user don't give initial value, and the
closure don't have default parameter.
```nushell
❯ let f = {|fib| {out: $fib.0, next: [$fib.1, ($fib.0 + $fib.1)]} }
❯ generate $f
Error: × The initial value is missing
╭─[entry #5:1:1]
1 │ generate $f
· ────┬───
· ╰── Missing intial value
╰────
help: Provide <initial> value in generate, or assigning default value to closure parameter
```
# Tests + Formatting
Added some test cases.
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
hustcer
pushed a commit
that referenced
this pull request
Oct 12, 2024
…4053) # Description Prevents errors when `=` is used before the end of: - strings in lists/records (with a symbol adjacent to the quotes) - raw strings ``` > ["=a"] Error: nu::parser::unknown_command × Unknown command. ╭─[entry #9:1:1] 1 │ ["=a"] · ───┬── · ╰── unknown command ╰──── ``` ``` > r#'=a'# Error: nu::parser::unknown_command × Unknown command. ╭─[entry #5:1:1] 1 │ r#'=a'# · ───┬─── · ╰── unknown command ╰──── ``` Closes #13902, closes #13901, closes #9879, closes #6401, closes #5806 # User-Facing Changes Variable names in environment shorthand assignments must satisfy `is_identifier`.
hustcer
pushed a commit
that referenced
this pull request
Mar 6, 2025
solution for #15242 adds "And" ``` ~/Projects/nushell> [[a, b]; [1., 2.], [3.,3.], [4., 6.]] | polars into-df | polars filter (((polars col a) > 2) and ((polars col b) < 5)) ╭───┬──────┬──────╮ │ # │ a │ b │ ├───┼──────┼──────┤ │ 0 │ 3.00 │ 3.00 │ ╰───┴──────┴──────╯ ``` adds "Or" ``` ~/Projects/nushell> [[a, b]; [1., 2.], [3.,3.], [4., 6.]] | polars into-df | polars filter (((polars col a) > 7) or ((polars col b) > 5)) ╭───┬──────┬──────╮ │ # │ a │ b │ ├───┼──────┼──────┤ │ 0 │ 4.00 │ 6.00 │ ╰───┴──────┴──────╯ ``` but not (yet) xor because polars doesn't have a direct expression for logical_xor ``` ~/Projects/nushell> [[a, b]; [1., 2.], [3.,3.], [4., 6.]] | polars into-df | polars filter (((polars col a) > 7) xor ((polars col b) > 5)) Error: nu::shell::operator_unsupported_type × The 'xor' operator does not work on values of type 'NuExpression'. ╭─[entry #5:1:94] 1 │ [[a, b]; [1., 2.], [3.,3.], [4., 6.]] | polars into-df | polars filter (((polars col a) > 7) xor ((polars col b) > 5)) · ─┬─┬ · │ ╰── NuExpression · ╰── does not support 'NuExpression' ╰──── ``` Co-authored-by: Jack Wright <56345+ayax79@users.noreply.github.com>
hustcer
pushed a commit
that referenced
this pull request
Mar 6, 2025
Fixes #15243
# Description
As noted in #15243, a record with more characters after it (e.g.,
`{a:b}/`) will cause an OOM due to an infinite loop, introduced by
#15023. This happens because the entire string `{a:b}/` is lexed as one
token and passed to `parse_record`, where it repeatedly lexes until it
hits the closing `}`. This PR detects such extra characters and reports
an error.
# User-Facing Changes
`{a:b}/` and other such constructions will no longer cause infinite
loops. Before #15023, you would've seen an "Unclosed delimiter" error
message, but this PR changes that to "Invalid characters."
```
Error: nu::parser::extra_token_after_closing_delimiter
× Invalid characters after closing delimiter
╭─[entry #5:1:7]
1 │ {a:b}/
· ┬
· ╰── invalid characters
╰────
help: Try removing them.
```
# Tests + Formatting
# After Submitting
hustcer
pushed a commit
that referenced
this pull request
Apr 8, 2025
No related issue. Decided in nushell's weekly meeting: see [meeting notes](https://hackmd.io/rA1YecqjRh6I5m8dTq7BHw) # Description Converting a date as a human readable string to a datetime: - currently: using the ``into datetime`` command - after this change: using ``date from-human`` command Also moved the ``--list-human`` flag to the new command. # User-Facing Changes - Users have to use a new command for parsing human readable datetimes. Result: ```nushell ~> date from-human --list ╭────┬───────────────────────────────────┬──────────────╮ │ # │ parseable human datetime examples │ result │ ├────┼───────────────────────────────────┼──────────────┤ │ 0 │ Today 18:30 │ in 6 hours │ │ 1 │ 2022-11-07 13:25:30 │ 2 years ago │ │ 2 │ 15:20 Friday │ in 6 days │ │ 3 │ This Friday 17:00 │ in 6 days │ │ 4 │ 13:25, Next Tuesday │ in 3 days │ │ 5 │ Last Friday at 19:45 │ 16 hours ago │ │ 6 │ In 3 days │ in 2 days │ │ 7 │ In 2 hours │ in 2 hours │ │ 8 │ 10 hours and 5 minutes ago │ 10 hours ago │ │ 9 │ 1 years ago │ a year ago │ │ 10 │ A year ago │ a year ago │ │ 11 │ A month ago │ a month ago │ │ 12 │ A week ago │ a week ago │ │ 13 │ A day ago │ a day ago │ │ 14 │ An hour ago │ an hour ago │ │ 15 │ A minute ago │ a minute ago │ │ 16 │ A second ago │ now │ │ 17 │ Now │ now │ ╰────┴───────────────────────────────────┴──────────────╯ ~> "2 days ago" | date from-human Thu, 3 Apr 2025 12:03:33 +0200 (2 days ago) ~> "2 days ago" | into datetime Error: nu::shell::datetime_parse_error × Unable to parse datetime: [2 days ago]. ╭─[entry #5:1:1] 1 │ "2 days ago" | into datetime · ──────┬───── · ╰── datetime parsing failed ╰──── help: Examples of supported inputs: * "5 pm" * "2020/12/4" * "2020.12.04 22:10 +2" * "2020-04-12 22:10:57 +02:00" * "2020-04-12T22:10:57.213231+02:00" * "Tue, 1 Jul 2003 10:52:37 +0200" ``` # Tests + Formatting Fmt, clippy 🆗 Tests 🆗 > Note: I was able to reactivate one unit test in the ``into datetime`` command # After Submitting Here since the user facing changes are significant, I think we should communicate in the released notes. Otherwise the automatically generated documentation should be enough IMO.
hustcer
pushed a commit
that referenced
this pull request
Apr 20, 2025
Closes #15543
# Description
1. Simplify code in ``datetime.rs`` based on a suggestion in my last PR
on "datetime from record"
1. Make ``into duration`` work with durations inside a record, provided
as a cell path
1. Make ``into duration`` work with durations as record
# User-Facing Changes
```nushell
# Happy paths
~> {d: '1hr'} | into duration d
╭───┬─────╮
│ d │ 1hr │
╰───┴─────╯
~> {week: 10, day: 2, sign: '+'} | into duration
10wk 2day
# Error paths and invalid usage
~> {week: 10, day: 2, sign: 'x'} | into duration
Error: nu::shell::incorrect_value
× Incorrect value.
╭─[entry #4:1:26]
1 │ {week: 10, day: 2, sign: 'x'} | into duration
· ─┬─ ──────┬──────
· │ ╰── encountered here
· ╰── Invalid sign. Allowed signs are +, -
╰────
~> {week: 10, day: -2, sign: '+'} | into duration
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #5:1:17]
1 │ {week: 10, day: -2, sign: '+'} | into duration
· ─┬ ──────┬──────
· │ ╰── encountered here
· ╰── number should be positive
╰────
~> {week: 10, day: '2', sign: '+'} | into duration
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #6:1:17]
1 │ {week: 10, day: '2', sign: '+'} | into duration
· ─┬─ ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰────
~> {week: 10, unknown: 1} | into duration
Error: nu:🐚:unsupported_input
× Unsupported input
╭─[entry #7:1:1]
1 │ {week: 10, unknown: 1} | into duration
· ───────────┬────────── ──────┬──────
· │ ╰── Column 'unknown' is not valid for a structured duration. Allowed columns are: week, day, hour, minute, second, millisecond, microsecond, nanosecond, sign
· ╰── value originates from here
╰────
~> {week: 10, day: 2, sign: '+'} | into duration --unit sec
Error: nu:🐚:incompatible_parameters
× Incompatible parameters.
╭─[entry #2:1:33]
1 │ {week: 10, day: 2, sign: '+'} | into duration --unit sec
· ──────┬────── ─────┬────
· │ ╰── the units should be included in the record
· ╰── got a record as input
╰────
```
# Tests + Formatting
- Add examples and integration tests for ``into duration``
- Add one test for ``into duration``
# After Submitting
If this is merged in time, I'll update my PR on the "datetime handling
highlights" for the release notes.
hustcer
pushed a commit
that referenced
this pull request
Jul 5, 2025
<!-- 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. --> Rel: #14429, #16079 Finishes up a TODO in the assignment type checking. - For regular assignment operations (only applies to `mut`), type checking is now done using `type_compatible` (which is what `let` uses) - This allows some mutable assignments to work which weren't allowed before Before: ```nushell let x: glob = "" # => ok, no error mut x: glob = ""; $x = "" # => Error: nu::parser::operator_incompatible_types # => # => × Types 'glob' and 'string' are not compatible for the '=' operator. # => ╭─[entry #6:1:19] # => 1 │ mut x: glob = ""; $x = "" # => · ─┬ ┬ ─┬ # => · │ │ ╰── string # => · │ ╰── does not operate between 'glob' and 'string' # => · ╰── glob # => ╰──── let x: number = 1 # ok, no error mut x: number = 1; $x = 2 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'number' and 'int' are not compatible for the '=' operator. # => ╭─[source:1:20] # => 1 │ mut x: number = 1; $x = 2 # => · ─┬ ┬ ┬ # => · │ │ ╰── int # => · │ ╰── does not operate between 'number' and 'int' # => · ╰── number # => ╰──── ``` After: ```nushell let x: glob = "" # ok, no error (same as before) mut x: glob = ""; $x = "" # ok, no error let x: number = 1 # ok, no error (same as before) mut x: number = 1; $x = 2 # ok, no error ``` - Properly type check compound operations. First checks if the operation (eg. `+` for `+=`) type checks successfully, and then checks if the assignment type checks successfully (also using `type_compatible`) - This fixes some issues where the "long version" of a compound assignment operator would error, but the compound assignment operator itself would not Before: ```nushell mut x = 1; $x = $x / 2 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'int' and 'float' are not compatible for the '=' operator. # => ╭─[entry #15:1:12] # => 1 │ mut x = 1; $x = $x / 2 # => · ─┬ ┬ ───┬── # => · │ │ ╰── float # => · │ ╰── does not operate between 'int' and 'float' # => · ╰── int # => ╰──── mut x = 1; $x /= 2 # uh oh, no error... mut x = (date now); $x = $x - 2019-05-10 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'datetime' and 'duration' are not compatible for the '=' operator. # => ╭─[entry #1:1:21] # => 1 │ mut x = (date now); $x = $x - 2019-05-10 # => · ─┬ ┬ ───────┬─────── # => · │ │ ╰── duration # => · │ ╰── does not operate between 'datetime' and 'duration' # => · ╰── datetime # => ╰──── mut x = (date now); $x -= 2019-05-10 # uh oh, no error... (the result of this is a duration, not a datetime) ``` After: ```nushell mut x = 1; $x = $x / 2 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'int' and 'float' are not compatible for the '=' operator. # => ╭─[entry #5:1:12] # => 1 │ mut x = 1; $x = $x / 2 # => · ─┬ ┬ ───┬── # => · │ │ ╰── float # => · │ ╰── does not operate between 'int' and 'float' # => · ╰── int # => ╰──── mut x = (date now); $x -= 2019-05-10 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'datetime' and 'datetime' are not compatible for the '-=' operator. # => ╭─[entry #11:1:21] # => 1 │ mut x = (date now); $x -= 2019-05-10 # => · ─┬ ─┬ ─────┬──── # => · │ │ ╰── datetime # => · │ ╰── does not operate between 'datetime' and 'datetime' # => · ╰── datetime # => ╰──── # => help: The result type of this operation is not compatible with the type of the variable. ``` This is technically a breaking change if you relied on the old behavior (for example, there was a test that broke after this change because it relied on `/=` improperly type checking) # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> * Mutable assignment operations now use the same type checking rules as normal assignments * For example, `$x = 123` now uses the same type checking rules as `let x = 123` or `mut x = 123` * Compound assignment operations now type check using the same rules as the operation they use * Assignment errors will also now highlight the invalid assignment operator in red # 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 > ``` --> Adds some tests for the examples given above # 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
hustcer
pushed a commit
that referenced
this pull request
Sep 8, 2025
Closes: #13817
The core requirement here is to have a way to track all exit status in a
pipeline. To achieve this without affecting command itself.
I created a new struct in `pipeline_data.rs`:
```rust
pub struct PipelineExecutionData {
pub body: PipelineData,
/// This field is using to track all exit status in a pipeline.
pub exit: Vec<Option<(Arc<Mutex<ExitStatusFuture>>, Span)>>,
}
```
Then I changed registers in `EvalContext` from `&'a mut [PipelineData]`
to `&'a mut [PipelineExecutionData]`. So the eval engine itself can
track exit status.
Then during evaluation, when nushell is going to execute
`Instruction::Call`. It takes `input.exit` first, then attach this into
`results.exit`. This is similar to the way nushell implements backtrace
feature.
After all of this, when nushell executes `Instruction::Drain`, or
printing pipeline. It iterates through *exit_futures* reversely. To see
if a command exits with non-zero status.
## Release notes summary - What our users need to know
This release will be add an experimental option for `pipefail`. This can
be set using `nu --experimental-options=['pipefail']`
> If set, the LAST_EXIT_CODE will be set to any command which exit with
a non-zero status, or zero if all commands in the pipeline exit
successfully.
```nushell
> ^false | print aa
aa
> $env.LAST_EXIT_CODE
1
```
It'd be more interesting if using it with
`$env.config.display_errors.exit_code = true`. Show users are able to
see which command is failed.
```nushell
> $env.config.display_errors.exit_code = true
> ^ls | ^false | print aa
aa
Error: nu::shell::non_zero_exit_code
× External command had a non-zero exit code
╭─[entry #5:1:8]
1 │ ^ls | ^false | print aa
· ──┬──
· ╰── exited with code 1
╰────
```
## Tasks after submitting
- [ ] Update the
[documentation](https://github.com/nushell/nushell.github.io)
---------
Co-authored-by: rose <132@ikl.sh>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps nu-ansi-term from 0.47.0 to 0.48.0.
Release notes
Sourced from nu-ansi-term's releases.
... (truncated)
Changelog
Sourced from nu-ansi-term's changelog.
Commits
98b763fBump version for 0.48.0 release (#45)024aa11Revert removal of the patch versions (#44)c32266cAdd support for hyperlinks and other OSC codes (#43)313eac4update dependencies (#42)135430bAdd resetted styling (#40)564d7baAdd feature: gnu_legacy mode for ansi styles (#39)773a306Updatewindows-systo 0.48 (#38)ff8bd8fRemove useless macro #[allow(dead_code)] (#37)47496f8Quick fix around doc tests regarding Color::prefix(). (#35)35481f4Unit tests update (#34)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)