Add support for real comparison operators by sophiajt · Pull Request #7 · nushell/nushell

sophiajt · 2019-05-18T01:28:36Z

Adds support for ==, !=, <, >, <=, and >=.

* Implement initial unicode movement and repaint * Finish updating unicode navigation

Tests for lex and lite parser

# Description follow up to #8529 cleaned up version of #8892 - the original syntax is okay ```nu def okay [rec: record] {} ``` - you can now add type annotations for fields if you know them before hand ```nu def okay [rec: record<name: string>] {} ``` - you can specify multiple fields ```nu def okay [person: record<name: string age: int>] {} # an optional comma is allowed def okay [person: record<name: string, age: int>] {} ``` - if annotations are specified, any use of the command will be type checked against the specified type ```nu def unwrap [result: record<ok: bool, value: any>] {} unwrap {ok: 2, value: "value"} # errors with Error: nu::parser::type_mismatch × Type mismatch. ╭─[entry #4:1:1] 1 │ unwrap {ok: 2, value: "value"} · ───────┬───── · ╰── expected record<ok: bool, value: any>, found record<ok: int, value: string> ╰──── ``` > here the error is in the `ok` field, since `any` is coerced into any type > as a result `unwrap {ok: true, value: "value"}` is okay - the key must be a string, either quoted or unquoted ```nu def err [rec: record<{}: list>] {} # errors with Error: × `record` type annotations key not string ╭─[entry #7:1:1] 1 │ def unwrap [result: record<{}: bool, value: any>] {} · ─┬ · ╰── must be a string ╰──── ``` - a key doesn't have to have a type in which case it is assumed to be `any` ```nu def okay [person: record<name age>] {} def okay [person: record<name: string age>] {} ``` - however, if you put a colon, you have to specify a type ```nu def err [person: record<name: >] {} # errors with Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #12:1:1] 1 │ def unwrap [res: record<name: >] { $res } · ┬ · ╰── expected type after colon ╰──── ``` # User-Facing Changes **[BREAKING CHANGES]** - this change adds a field to `SyntaxShape::Record` so any plugins that used it will have to update and include the field. though if you are unsure of the type the record expects, `SyntaxShape::Record(vec![])` will suffice

…10430) should close #10406 # Description when writing a script, with variables you try to `ls` or `open`, you will get a "directory not found" error but the variable won't be expanded and you won't be able to see which one of the variable was the issue... this PR adds this information to the error. # User-Facing Changes let's define a variable ```nushell let does_not_exist = "i_do_not_exist_in_the_current_directory" ``` ### before ```nushell > open $does_not_exist Error: nu::shell::directory_not_found × Directory not found ╭─[entry #7:1:1] 1 │ open $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── ``` ```nushell > ls $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #8:1:1] 1 │ ls $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── ``` ### after ```nushell > open $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #3:1:1] 1 │ open $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist ``` ```nushell > ls $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #4:1:1] 1 │ ls $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist ``` # Tests + Formatting shouldn't harm anything 🤞 # After Submitting

should close #10549 # Description this PR is twofold - uses `to nuon --raw` in the error messages to make sure #10549 is solved and makes a difference between `"1"` and `1` - tries to introduce slightly better errors, i.e. by putting left / right on new lines => this should hopefully help when the values become a bit big 😋 # User-Facing Changes the original issue: ```nushell > assert equal {one:1 two:2} {one:"1" two:"2"} Error: × Assertion failed. ╭─[entry #3:1:1] 1 │ assert equal {one:1 two:2} {one:"1" two:"2"} · ───────────────┬─────────────── · ╰── These are not equal. Left : '{one: 1, two: 2}' Right : '{one: "1", two: "2"}' ╰──── ``` a sample for all the assertions and their new messages ```nushell > assert equal {one:1 two:2} {one:"1" two:"2"} Error: × Assertion failed. ╭─[entry #3:1:1] 1 │ assert equal {one:1 two:2} {one:"1" two:"2"} · ───────────────┬─────────────── · ╰── These are not equal. Left : '{one: 1, two: 2}' Right : '{one: "1", two: "2"}' ╰──── ``` ```nushell > assert equal 1 2 Error: × Assertion failed. ╭─[entry #4:1:1] 1 │ assert equal 1 2 · ─┬─ · ╰── These are not equal. Left : '1' Right : '2' ╰──── ``` ```nushell > assert less 3 1 Error: × Assertion failed. ╭─[entry #6:1:1] 1 │ assert less 3 1 · ─┬─ · ╰── The condition *left < right* is not satisfied. Left : '3' Right : '1' ╰──── ``` ```nushell > assert less or equal 3 1 Error: × Assertion failed. ╭─[entry #7:1:1] 1 │ assert less or equal 3 1 · ─┬─ · ╰── The condition *left <= right* is not satisfied. Left : '3' Right : '1' ╰──── ``` ```nushell > assert greater 1 3 Error: × Assertion failed. ╭─[entry #8:1:1] 1 │ assert greater 1 3 · ─┬─ · ╰── The condition *left > right* is not satisfied. Left : '1' Right : '3' ╰──── ``` ```nushell > assert greater or equal 1 3 Error: × Assertion failed. ╭─[entry #9:1:1] 1 │ assert greater or equal 1 3 · ─┬─ · ╰── The condition *left < right* is not satisfied. Left : '1' Right : '3' ╰──── ``` ```nushell > assert length [1 2 3] 2 Error: × Assertion failed. ╭─[entry #10:1:1] 1 │ assert length [1 2 3] 2 · ────┬──── · ╰── This does not have the correct length: value : [1, 2, 3] length : 3 expected : 2 ╰──── ``` ```nushell > assert length [1 "2" 3] 2 Error: × Assertion failed. ╭─[entry #11:1:1] 1 │ assert length [1 "2" 3] 2 · ─────┬───── · ╰── This does not have the correct length: value : [1, "2", 3] length : 3 expected : 2 ╰──── ``` ```nushell > assert str contains "foo" "bar" Error: × Assertion failed. ╭─[entry #13:1:1] 1 │ assert str contains "foo" "bar" · ─────┬───── · ╰── This does not contain '($right)'. value: "foo" ╰──── ``` # Tests + Formatting # After Submitting

Fixes #10644 ## the deprecation errors - using `--pretty` alone` will run the command and give a warning ```nushell > {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 Error: × Deprecated option ╭─[entry #7:1:1] 1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 · ───┬── · ╰── `to xml --pretty {int}` is deprecated and will be removed in 0.87. ╰──── help: Please use `--indent {int}` instead. <note> <remember>Event</remember> </note> ``` - using `--pretty` and `--indent` will give the deprecation warning and throw an error ```nushell > {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4 Error: × Deprecated option ╭─[entry #9:1:1] 1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4 · ───┬── · ╰── `to xml --pretty {int}` is deprecated and will be removed in 0.87. ╰──── help: Please use `--indent {int}` instead. Error: nu:🐚:incompatible_parameters × Incompatible parameters. ╭─[entry #9:1:1] 1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4 · ┬ ┬ · │ ╰── and --indent · ╰── Cannot pass --pretty ╰──── ```

…ushell#10430) should close nushell#10406 # Description when writing a script, with variables you try to `ls` or `open`, you will get a "directory not found" error but the variable won't be expanded and you won't be able to see which one of the variable was the issue... this PR adds this information to the error. # User-Facing Changes let's define a variable ```nushell let does_not_exist = "i_do_not_exist_in_the_current_directory" ``` ### before ```nushell > open $does_not_exist Error: nu::shell::directory_not_found × Directory not found ╭─[entry nushell#7:1:1] 1 │ open $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── ``` ```nushell > ls $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry nushell#8:1:1] 1 │ ls $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── ``` ### after ```nushell > open $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry nushell#3:1:1] 1 │ open $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist ``` ```nushell > ls $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry nushell#4:1:1] 1 │ ls $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist ``` # Tests + Formatting shouldn't harm anything 🤞 # After Submitting

should close nushell#10549 # Description this PR is twofold - uses `to nuon --raw` in the error messages to make sure nushell#10549 is solved and makes a difference between `"1"` and `1` - tries to introduce slightly better errors, i.e. by putting left / right on new lines => this should hopefully help when the values become a bit big 😋 # User-Facing Changes the original issue: ```nushell > assert equal {one:1 two:2} {one:"1" two:"2"} Error: × Assertion failed. ╭─[entry nushell#3:1:1] 1 │ assert equal {one:1 two:2} {one:"1" two:"2"} · ───────────────┬─────────────── · ╰── These are not equal. Left : '{one: 1, two: 2}' Right : '{one: "1", two: "2"}' ╰──── ``` a sample for all the assertions and their new messages ```nushell > assert equal {one:1 two:2} {one:"1" two:"2"} Error: × Assertion failed. ╭─[entry nushell#3:1:1] 1 │ assert equal {one:1 two:2} {one:"1" two:"2"} · ───────────────┬─────────────── · ╰── These are not equal. Left : '{one: 1, two: 2}' Right : '{one: "1", two: "2"}' ╰──── ``` ```nushell > assert equal 1 2 Error: × Assertion failed. ╭─[entry nushell#4:1:1] 1 │ assert equal 1 2 · ─┬─ · ╰── These are not equal. Left : '1' Right : '2' ╰──── ``` ```nushell > assert less 3 1 Error: × Assertion failed. ╭─[entry nushell#6:1:1] 1 │ assert less 3 1 · ─┬─ · ╰── The condition *left < right* is not satisfied. Left : '3' Right : '1' ╰──── ``` ```nushell > assert less or equal 3 1 Error: × Assertion failed. ╭─[entry nushell#7:1:1] 1 │ assert less or equal 3 1 · ─┬─ · ╰── The condition *left <= right* is not satisfied. Left : '3' Right : '1' ╰──── ``` ```nushell > assert greater 1 3 Error: × Assertion failed. ╭─[entry nushell#8:1:1] 1 │ assert greater 1 3 · ─┬─ · ╰── The condition *left > right* is not satisfied. Left : '1' Right : '3' ╰──── ``` ```nushell > assert greater or equal 1 3 Error: × Assertion failed. ╭─[entry nushell#9:1:1] 1 │ assert greater or equal 1 3 · ─┬─ · ╰── The condition *left < right* is not satisfied. Left : '1' Right : '3' ╰──── ``` ```nushell > assert length [1 2 3] 2 Error: × Assertion failed. ╭─[entry nushell#10:1:1] 1 │ assert length [1 2 3] 2 · ────┬──── · ╰── This does not have the correct length: value : [1, 2, 3] length : 3 expected : 2 ╰──── ``` ```nushell > assert length [1 "2" 3] 2 Error: × Assertion failed. ╭─[entry nushell#11:1:1] 1 │ assert length [1 "2" 3] 2 · ─────┬───── · ╰── This does not have the correct length: value : [1, "2", 3] length : 3 expected : 2 ╰──── ``` ```nushell > assert str contains "foo" "bar" Error: × Assertion failed. ╭─[entry nushell#13:1:1] 1 │ assert str contains "foo" "bar" · ─────┬───── · ╰── This does not contain '($right)'. value: "foo" ╰──── ``` # Tests + Formatting # After Submitting

…ll#10660) Fixes nushell#10644 ## the deprecation errors - using `--pretty` alone` will run the command and give a warning ```nushell > {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 Error: × Deprecated option ╭─[entry nushell#7:1:1] 1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 · ───┬── · ╰── `to xml --pretty {int}` is deprecated and will be removed in 0.87. ╰──── help: Please use `--indent {int}` instead. <note> <remember>Event</remember> </note> ``` - using `--pretty` and `--indent` will give the deprecation warning and throw an error ```nushell > {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4 Error: × Deprecated option ╭─[entry nushell#9:1:1] 1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4 · ───┬── · ╰── `to xml --pretty {int}` is deprecated and will be removed in 0.87. ╰──── help: Please use `--indent {int}` instead. Error: nu:🐚:incompatible_parameters × Incompatible parameters. ╭─[entry nushell#9:1:1] 1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4 · ┬ ┬ · │ ╰── and --indent · ╰── Cannot pass --pretty ╰──── ```

@kubouch

# Description While #11057 is merged, it's hard to tell the difference between `--flag: bool` and `--flag`, and it makes user hard to read custom commands' signature, and hard to use them correctly. After discussion, I think we can deprecate `--flag: bool` usage, and encourage using `--flag` instead. # User-Facing Changes The following code will raise warning message, but don't stop from running. ```nushell ❯ def florb [--dry-run: bool, --another-flag] { "aaa" }; florb Error: × Deprecated: --flag: bool ╭─[entry #7:1:1] 1 │ def florb [--dry-run: bool, --another-flag] { "aaa" }; florb · ──┬─ · ╰── `--flag: bool` is deprecated. Please use `--flag` instead, more info: https://www.nushell.sh/book/custom_commands.html ╰──── aaa ``` cc @kubouch # Tests + Formatting Done # After Submitting - [ ] Add more information under https://www.nushell.sh/book/custom_commands.html to indicate `--dry-run: bool` is not allowed, - [ ] remove `: bool` from custom commands between 0.89 and 0.90 --------- Co-authored-by: Antoine Stevan <44101798+amtoine@users.noreply.github.com>

@kubouch

# Description While nushell#11057 is merged, it's hard to tell the difference between `--flag: bool` and `--flag`, and it makes user hard to read custom commands' signature, and hard to use them correctly. After discussion, I think we can deprecate `--flag: bool` usage, and encourage using `--flag` instead. # User-Facing Changes The following code will raise warning message, but don't stop from running. ```nushell ❯ def florb [--dry-run: bool, --another-flag] { "aaa" }; florb Error: × Deprecated: --flag: bool ╭─[entry nushell#7:1:1] 1 │ def florb [--dry-run: bool, --another-flag] { "aaa" }; florb · ──┬─ · ╰── `--flag: bool` is deprecated. Please use `--flag` instead, more info: https://www.nushell.sh/book/custom_commands.html ╰──── aaa ``` cc @kubouch # Tests + Formatting Done # After Submitting - [ ] Add more information under https://www.nushell.sh/book/custom_commands.html to indicate `--dry-run: bool` is not allowed, - [ ] remove `: bool` from custom commands between 0.89 and 0.90 --------- Co-authored-by: Antoine Stevan <44101798+amtoine@users.noreply.github.com>

# Description Fix wrong casting which is related to #12974 (comment) # User-Facing Changes AS-IS (before fixing) ``` $ "-10000PiB" | into filesize 6.2 EiB <--- Wrong casted value $ "10000PiB" | into filesize -6.2 EiB <--- Wrong casted value ``` TO-BE (after fixing) ``` $ "-10000PiB" | into filesize Error: nu::shell::cant_convert × Can't convert to filesize. ╭─[entry #6:1:1] 1 │ "-10000PiB" | into filesize · ─────┬───── · ╰── can't convert string to filesize ╰──── $ "10000PiB" | into filesize Error: nu:🐚:cant_convert × Can't convert to filesize. ╭─[entry #7:1:1] 1 │ "10000PiB" | into filesize · ─────┬──── · ╰── can't convert string to filesize ╰──── ```

# Description After this pr, nushell is able to raise errors with a backtrace, which should make users easier to debug. To enable the feature, users need to set env variable via `$env.NU_BACKTRACE = 1`. But yeah it might not work perfectly, there are some corner cases which might not be handled. I think it should close #13379 in another way. ### About the change The implementation mostly contained with 2 parts: 1. introduce a new `ChainedError` struct as well as a new `ShellError::ChainedError` variant. If `eval_instruction` returned an error, it converts the error to `ShellError::ChainedError`. `ChainedError` struct is responsable to display errors properly. It needs to handle the following 2 cases: - if we run a function which runs `error make` internally, it needs to display the error itself along with caller span. - if we run a `error make` directly, or some commands directly returns an error, we just want nushell raise an error about `error make`. 2. Attach caller spans to `ListStream` and `ByteStream`, because they are lazy streams, and *only* contains the span that runs it directly(like `^false`, for example), so nushell needs to add all caller spans to the stream. For example: in `def a [] { ^false }; def b [] { a; 33 }; b`, when we run `b`, which runs `a`, which runs `^false`, the `ByteStream` only contains the span of `^false`, we need to make it contains the span of `a`, so nushell is able to get all spans if something bad happened. This behavior is happened after running `Instruction::Call`, if it returns a `ByteStream` and `ListStream`, it will call `push_caller_span` method to attach call spans. # User-Facing Changes It's better to demostrate how it works by examples, given the following definition: ```nushell > $env.NU_BACKTRACE = 1 > def a [x] { if $x == 3 { error make {msg: 'a custom error'}}} > def a_2 [x] { if $x == 3 { ^false } else { $x } } > def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } } > def b [--list-stream --external] { if $external == true { # error with non-zero exit code, which is generated from external command. a_2 1; a_2 3; a_2 2 } else if $list_stream == true { # error generated by list-stream a_3 1; a_3 3; a_3 2 } else { # error generated by command directly a 1; a 2; a 3 } } ``` Run `b` directly shows the following error: <details> ```nushell Error: chained_error × oops ╭─[entry #27:1:1] 1 │ b · ┬ · ╰── error happened when running this ╰──── Error: chained_error × oops ╭─[entry #26:10:19] 9 │ # error generated by command directly 10 │ a 1; a 2; a 3 · ┬ · ╰── error happened when running this 11 │ } ╰──── Error: × a custom error ╭─[entry #6:1:26] 1 │ def a [x] { if $x == 3 { error make {msg: 'a custom error'}}} · ─────┬──── · ╰── originates from here ╰──── ``` </details> Run `b --list-stream` shows the following error <details> ```nushell Error: chained_error × oops ╭─[entry #28:1:1] 1 │ b --list-stream · ┬ · ╰── error happened when running this ╰──── Error: nu:🐚:eval_block_with_input × Eval block failed with pipeline input ╭─[entry #26:7:16] 6 │ # error generated by list-stream 7 │ a_3 1; a_3 3; a_3 2 · ─┬─ · ╰── source value 8 │ } else { ╰──── Error: nu:🐚:eval_block_with_input × Eval block failed with pipeline input ╭─[entry #23:1:29] 1 │ def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } } · ┬ · ╰── source value ╰──── Error: × a custom error inside list stream ╭─[entry #23:1:44] 1 │ def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } } · ─────┬──── · ╰── originates from here ╰──── ``` </details> Run `b --external` shows the following error: <details> ```nushell Error: chained_error × oops ╭─[entry #29:1:1] 1 │ b --external · ┬ · ╰── error happened when running this ╰──── Error: nu:🐚:eval_block_with_input × Eval block failed with pipeline input ╭─[entry #26:4:16] 3 │ # error with non-zero exit code, which is generated from external command. 4 │ a_2 1; a_2 3; a_2 2 · ─┬─ · ╰── source value 5 │ } else if $list_stream == true { ╰──── Error: nu:🐚:non_zero_exit_code × External command had a non-zero exit code ╭─[entry #7:1:29] 1 │ def a_2 [x] { if $x == 3 { ^false } else { $x } } · ──┬── · ╰── exited with code 1 ╰──── ``` </details> It also added a message to guide the usage of NU_BACKTRACE, see the last line in the following example: ```shell ls asdfasd Error: nu:🐚:io::not_found × I/O error ╰─▶ × Entity not found ╭─[entry #17:1:4] 1 │ ls asdfasd · ───┬─── · ╰── Entity not found ╰──── help: The error occurred at '/home/windsoilder/projects/nushell/asdfasd' set the `NU_BACKTRACE=1` environment variable to display a backtrace. ``` # Tests + Formatting Added some tests for the behavior. # After Submitting

Issue #12289, can be closed when this is merged # Description Currently, the ``into datetime`` command's signature indicates that it supports input as record, but it was actually not supported. This PR implements this feature. # User-Facing Changes ``into datetime``'s signature changed (see comments) **Happy paths** Note: I'm in +02:00 timezone. ```nushell > date now | into record | into datetime Fri, 4 Apr 2025 18:32:34 +0200 (now) > {year: 2025, month: 12, day: 6, second: 59} | into datetime | into record ╭─────────────┬────────╮ │ year │ 2025 │ │ month │ 12 │ │ day │ 6 │ │ hour │ 0 │ │ minute │ 0 │ │ second │ 59 │ │ millisecond │ 0 │ │ microsecond │ 0 │ │ nanosecond │ 0 │ │ timezone │ +02:00 │ ╰─────────────┴────────╯ > {day: 6, second: 59, timezone: '-06:00'} | into datetime | into record ╭─────────────┬────────╮ │ year │ 2025 │ │ month │ 4 │ │ day │ 6 │ │ hour │ 0 │ │ minute │ 0 │ │ second │ 59 │ │ millisecond │ 0 │ │ microsecond │ 0 │ │ nanosecond │ 0 │ │ timezone │ -06:00 │ ╰─────────────┴────────╯ ``` **Edge cases** ```nushell {} | into datetime Fri, 4 Apr 2025 18:35:19 +0200 (now) ``` **Error paths** - A key has a wrong type ```nushell > {month: 12, year: '2023'} | into datetime Error: nu::shell::only_supports_this_input_type × Input type not supported. ╭─[entry #8:1:19] 1 │ {month: 12, year: '2023'} | into datetime · ───┬── ──────┬────── · │ ╰── only int input data is supported · ╰── input type: string ╰──── ``` ```nushell > {month: 12, year: 2023, timezone: 100} | into datetime Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #10:1:35] 1 │ {month: 12, year: 2023, timezone: 100} | into datetime · ─┬─ ──────┬────── · │ ╰── only string input data is supported · ╰── input type: int ╰──── ``` - Key has the right type but value invalid (e.g. month=13, or day=0) ```nushell > {month: 13, year: 2023} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #9:1:1] 1 │ {month: 13, year: 2023} | into datetime · ───────────┬─────────── ──────┬────── · │ ╰── one of more values are incorrect and do not represent valid date · ╰── encountered here ╰──── ``` ```nushell > {hour: 1, minute: 1, second: 70} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #3:1:1] 1 │ {hour: 1, minute: 1, second: 70} | into datetime · ────────────────┬─────────────── ──────┬────── · │ ╰── one of more values are incorrect and do not represent valid time · ╰── encountered here ╰──── ``` - Timezone has right type but is invalid ```nushell > {month: 12, year: 2023, timezone: "+100:00"} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #11:1:35] 1 │ {month: 12, year: 2023, timezone: "+100:00"} | into datetime · ────┬──── ──────┬────── · │ ╰── encountered here · ╰── invalid timezone ╰──── ``` - Record contains an invalid key ```nushell > {month: 12, year: 2023, unknown: 1} | into datetime Error: nu:🐚:unsupported_input × Unsupported input ╭─[entry #12:1:1] 1 │ {month: 12, year: 2023, unknown: 1} | into datetime · ─────────────────┬───────────────── ──────┬────── · │ ╰── Column 'unknown' is not valid for a structured datetime. Allowed columns are: year, month, day, hour, minute, second, millisecond, microsecond, nanosecond, timezone · ╰── value originates from here ╰──── ``` - If several issues are present, the user can get the error msg for only one, though ```nushell > {month: 20, year: '2023'} | into datetime Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #7:1:19] 1 │ {month: 20, year: '2023'} | into datetime · ───┬── ──────┬────── · │ ╰── only int input data is supported · ╰── input type: string ╰ ``` # Tests + Formatting Tests added Fmt + clippy OK # After Submitting Maybe indicate that in the release notes I added an example in the command, so the documentation will be automatically updated.

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.

…tor (#15623) # Description Fixes: #15510 I think it's introduced by #14653, which changes `and/or` to `match` expression. After looking into `compile_match`, it's important to collect the value before matching this. ```rust // Important to collect it first builder.push(Instruction::Collect { src_dst: match_reg }.into_spanned(match_expr.span))?; ``` This pr is going to apply the logic while compiling `and/or` operation. # User-Facing Changes The following will raise a reasonable error: ```nushell > (nu --testbin cococo false) and true Error: nu::shell::operator_unsupported_type × The 'and' operator does not work on values of type 'string'. ╭─[entry #7:1:2] 1 │ (nu --testbin cococo false) and true · ─┬ ─┬─ · │ ╰── does not support 'string' · ╰── string ╰──── ``` # Tests + Formatting Added 1 test. # After Submitting Maybe need to update doc nushell/nushell.github.io#1876 --------- Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>

Closes #14469 # Description - ~~Implement the ``--unit`` conversion in "into int" command~~ - New ``ShellError::InvalidUnit`` unit if users enter wrong units - Made ``ShellError::CantConvertToDuration`` more generic: became ``CantConvertToUnit`` - Tried to improve the way we parse units and get the supported units. It's not complete, though, I will continue this refactoring in another PR. But I already did some small refactorings in the "format duration" and "format filesize" commands - Add tests for "format filesize" and "format duration" # User-Facing Changes ```nu ~> 1MB | format filesize sec Error: nu::shell::invalid_unit × Invalid unit ╭─[entry #7:1:23] 1 │ 1MB | format filesize sec · ─┬─ · ╰── encountered here ╰──── help: Supported units are: B, kB, MB, GB, TB, PB, EB, KiB, MiB, GiB, TiB, PiB, EiB ```

# Description This PR makes the span of a pipeline accessible through `metadata`, meaning it's possible to get the span of a pipeline without collecting it. Examples: ```nushell ls | metadata # => ╭────────┬────────────────────╮ # => │ │ ╭───────┬────────╮ │ # => │ span │ │ start │ 170218 │ │ # => │ │ │ end │ 170220 │ │ # => │ │ ╰───────┴────────╯ │ # => │ source │ ls │ # => ╰────────┴────────────────────╯ ``` ```nushell ls | metadata access {|meta| error make {msg: "error", label: {text: "here", span: $meta.span}} } # => Error: × error # => ╭─[entry #7:1:1] # => 1 │ ls | metadata access {|meta| # => · ─┬ # => · ╰── here # => 2 │ error make {msg: "error", label: {text: "here", span: $meta.span}} # => ╰──── ``` Here's an example that wouldn't be possible before, since you would have to use `metadata $in` to get the span, collecting the (infinite) stream ```nushell generate {|x=0| {out: 0, next: 0} } | metadata access {|meta| # do whatever with stream error make {msg: "error", label: {text: "here", span: $meta.span}} } # => Error: × error # => ╭─[entry #16:1:1] # => 1 │ generate {|x=0| {out: 0, next: 0} } | metadata access {|meta| # => · ────┬─── # => · ╰── here # => 2 │ # do whatever with stream # => ╰──── ``` I haven't done the tests or anything yet since I'm not sure how we feel about having this as part of the normal metadata, rather than a new command like `metadata span` or something. We could also have a `metadata access` like functionality for that with an optional closure argument potentially. # User-Facing Changes * The span of a pipeline is now available through `metadata` and `metadata access` without collecting a stream. # Tests + Formatting TODO # After Submitting N/A

This PR adds the `toolkit run pr` and `toolkit download pr` commands to `toolkit`. This is a more fleshed out version of the snippet shared in #16633, with robust error handling and cross-platform unzip support. When using `toolkit run pr`, the script will also check if the most recent binary for that PR has already been downloaded, and if so it will run that instead. I tried to make the error reporting as good as a built-in command to see how difficult that would be, and with use of the `--head: oneof<>` trick, it turned out pretty good. With access to the call span, the workflow is very similar to when writing a built-in command. I also used a `Spanned`-like record, which helped as well. ```nushell toolkit run pr 16740 # => Error: nu::shell::error # => # => × Command not found # => ╭─[entry #4:1:26] # => 1 │ overlay use -pr toolkit; toolkit run pr 16740 # => · ───────┬────── # => · ╰── requires `gh` # => ╰──── # => help: Please install the `gh` commandline tool ``` <details> <summary>More error reporting notes</summary> In an earlier version of the script, `run pr` called `download pr` directly. I ended up changing the way this worked so that `run pr` could use the workflow_id. Here's a couple snippets I thought were neat from this older version.   **Passing span via `--head`:** ```nushell def download [--head: oneof<>] { let span = $head | default (metadata $head).span error make {msg: "a", label: {text: here, span: $span}} } def run [--head: oneof<>] { let span = (metadata $head).span download --head=$span } download # => Error: nu:🐚:error # => # => × a # => ╭─[entry #6:1:1] # => 1 │ download # => · ────┬─── # => · ╰── here # => ╰──── run # => Error: nu:🐚:error # => # => × a # => ╭─[entry #7:1:1] # => 1 │ run # => · ─┬─ # => · ╰── here # => ╰──── ``` **Using "spanned" number as CLI parameter and as internal caller parameter** ```nushell def download [number: oneof<int, record<item: int, span: record>>] { let number = match $number { {item: $_, span: $_} => $number, $val => {item: $number, span: (metadata $number).span} } error make {msg: "a", label: {text: here, span: $number.span}} } def run [number: int] { let number = {item: $number, span: (metadata $number).span} download $number } download 123 # => Error: nu:🐚:error # => # => × a # => ╭─[entry #9:1:10] # => 1 │ download 123 # => · ─┬─ # => · ╰── here # => ╰──── run 123 # => Error: nu:🐚:error # => # => × a # => ╭─[entry #10:1:5] # => 1 │ run 123 # => · ─┬─ # => · ╰── here # => ╰──── ``` </details> ## Release notes summary - What our users need to know The toolkit in the Nushell repository can now download and run PRs by downloading artifacts from CI runs. It can be run like this: ```nushell use toolkit toolkit run pr <number> ```

## User-facing Changes * New arguments! (`error make "hello"`) * New parts for `error_struct`! (`error make {inner: [] labels: [] ...}`) * Pipeline inputs for chained errors! (`try {error make foo} catch {error make bar}`) * Pipeline inputs for normal errors! (`"help" | error make`) * External errors! (`error make {src: {path: $nu.cofig-path} ...}`) * Backwards compatibility! ### Arguments and Inputs The main changes are in how the arguments are passed. Everything is still backwards compatible with the old `error make` commands, there's just a nice extra layer we get from the pipeline and a few new args (that were already added in #17037). There are some new ways to (hopefully intentionally) cause an error, such as using a naked `error make`, pipelines from records and simple string input! #### Inputs Because `error make` will just make an error anyway, it can technically take any input to make an error, but only properly formatted record input will create a chain. the `x | f $in` pattern can be used for string input, if that is more comfortable. #### With no arguments This is a completely new way to do this, with no arguments the `error make` invocation is highlighted, along with a simple `originates from here` message. This makes normal errors very easy to create without any special message setup. ``` > error make Error: nu::shell::error × originates from here ╭─[entry #4:1:1] 1 │ error make · ────────── ╰──── ``` #### Create a single argument * With pipeline input: `{msg: foo} | error make` * With an argument: `error make {msg: foo}` * With a string argument: `error make foo` ``` Error: nu:🐚:error × foo ╭─[entry #2:1:12] 1 │ error make {msg: foo} · ────────── ╰──── ``` #### Chaining errors together These will automatically create a chain of errors, placing the pipeline as an `inner` to the argument. This can very easily be used to get a bit more detail in a try loop using the naked `error make`: ``` Error: nu:🐚:error × originates from here ╭─[source:1:31] 1 │ try {error make "foo"} catch {error make} · ────────── ╰──── Error: nu:🐚:error × foo ╭─[source:1:6] 1 │ try {error make "foo"} catch {error make} · ────────── ╰──── ``` Or with more complex errors: * With both, combining the errors: `{msg: foo} | error make bar` * With the raw error from try: `try {error make foo} catch {error make bar}` Both are equivalent to: * `error make {msg: bar inner: [{msg: foo}]}` ``` Error: nu:🐚:error × bar ╭─[entry #1:1:29] 1 │ try {error make foo} catch {error make bar} · ────────── ╰──── Error: nu:🐚:error × foo ╭─[entry #1:1:6] 1 │ try {error make foo} catch {error make bar} · ────────── ╰──── ``` ### Labels As is noticeable in the examples above, simple errors no longer use an extra line for the label. If no label is present, `error make` will place a bar under the span of itself or the argument to `error make`. Labels have also gotten a bit of a rewrite, but they're pretty much the same as those in #17037, except for `label`, which is now only a single label (not `oneof<list, label>`). #### Simple Labels `label.text` and `labels.*.text` is no longer required for a span to show up, an empty text will simply underline. This example can either use `label: $record` or be written as `labels: [$record]`: ``` > def f [x] { error make {msg: here label: {span: (metadata $x).span}} } f abcd Error: nu::shell::error × here ╭─[entry #7:4:3] 3 │ } 4 │ f abcd · ──── ╰──── ``` #### Multiple labels Any number of labels can be added in the `labels` column, allowing for more detailed error messages, especially for functions: ``` > def f [x y z] { error make {msg: here labels: [ {text: "there" span: (metadata $x).span} {text: "everywhere" span: (metadata $y).span} {text: "somewhere" span: (metadata $z).span} ] } } f abcd [x y z] {d: a} Error: nu:🐚:error × here ╭─[entry #11:9:3] 8 │ } 9 │ f abcd [x y z] {d: a} · ──┬─ ───┬─── ───┬── · │ │ ╰── somewhere · │ ╰── everywhere · ╰── there ╰──── ``` #### External sources There is a `ShellError::OutsideSpannedLabeledError` that can be used to refer to external sources, not just the internal nushell spanns. This has been expanded to allow the multi-label stuff to work using the new `src` column: ``` > "foo\nbar\nbaz" | save -f /tmp/foo.bar error make { msg: 'error here' src: {path: /tmp/foo.bar} labels: [ {text: "this" span: {start: 4 end: 7}} ] } Error: nu:🐚:outside × error here ╭─[/tmp/foo.bar:2:1] 1 │ foo 2 │ bar · ─┬─ · ╰── this 3 │ baz ╰──── ``` ### Errors That Can't be Caught These will not work since `try` will never get parsed: - `try {1 + ""} catch {error make badmath}` - (TODO: Add more examples) ## Internal Changes Most of the parsing from an error record to an actual error is now moved into `nu-protocol`, using `FromValue` to turn it into a useful internal type. ### `nu-protocol::LabeledError` This struct has a few changes, the main one being the type of `LabeledError.inner`. It is now a `ShellError`, not another `LabeledError`. It should be trivial to do a `.into()` for things that already use `LabeledError.with_inner(x)`. ### `nu-protocol::ShellError::into_value` I renamed the old `into_value` to `into_full_value` to better say what it is, since it doesn't just do the `IntoValue::into_value` method, it also requires some context to create the `Value`. Now `ShellError` has an `IntoValue` implementation matching other types. ### `nu-protocol::ShellError::{OutsideSource, OutsideSourceNoUrl}` Miette's derived types don't have a nice way to maybe include a url, so there are now two types! These allow using multiple labels on outside sources. They are used internally for the new `{src: {}}` part of the `error_struct`, and they look a lot more like the `LabeledError`, but without the need for a separate type and all the fun `impl`s that would require for the `Diagnostic::source_code` method. ### Misc * Spelling fix: `into_chainned` => `into_chained` ## Current bugs: - [x] `OutsideSpannedLabeledError` The inner most error of `try {']' from nuon} catch {error make}` will reference `span: {start: 0, end: 1}`, which in `']' from nuon` will point to the `]` character, but when it does this in `error make` as an input it will point to the very first character (probably the `n` in `nu`). ## Release notes summary - What our users need to know ### New `error make` functionality! * New arguments! (`error make "hello"`) * New parts for `error_struct`! (`error make {inner: [] labels: [] ...}`) * Pipeline inputs for chained errors! (`try {error make foo} catch {error make bar}`) * Pipeline inputs for normal errors! (`"help" | error make`) * External errors! (`error make {src: {path: $nu.cofig-path} ...}`) * Backwards compatibility! ## Tasks after submitting  - [ ] Update the [documentation](https://github.com/nushell/nushell.github.io)

Add support for real comparison operators

76c2959

sophiajt merged commit d9135c4 into nushell:master May 18, 2019

ahkrr pushed a commit to ahkrr/nushell that referenced this pull request Jun 24, 2021

Unicode movement (nushell#7)

bf161b1

* Implement initial unicode movement and repaint * Finish updating unicode navigation

elferherrera pushed a commit to elferherrera/nushell that referenced this pull request Feb 7, 2022

Merge pull request nushell#7 from elferherrera/tests

d0be193

Tests for lex and lite parser

gagero mentioned this pull request Jul 11, 2022

Cannot launch most binaries form ~/.local/bin/ #6015

Closed

Hofer-Julian pushed a commit to Hofer-Julian/nushell that referenced this pull request Jan 27, 2023

Fix edit on github link (nushell#9)

742a150

references (nushell#7)

sophiajt deleted the real_operators branch September 2, 2023 16:07

richardwesthaver mentioned this pull request Feb 8, 2024

let binding an existing variable to an invalid object drops the previous binding #11799

Open

132ikl mentioned this pull request Nov 18, 2024

#7190 Added sort_by config to ls configs (Fixes #7190) #14331

Closed

132ikl mentioned this pull request Jan 28, 2025

Different blocking behavior for start depending on platform #14947

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for real comparison operators#7

Add support for real comparison operators#7
sophiajt merged 1 commit intonushell:masterfrom
sophiajt:real_operators

sophiajt commented May 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

sophiajt commented May 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant