Complete commands a bit better #9

sophiajt · 2019-05-18T14:06:41Z

This checks the prefix of commands so that they autocomplete a bit better.

Removed need to collect grapheme indices into a Vec. Also, we can slice the buffer from or to the insertion point to not have to iterate through all of the indices.

# Description Adds improved errors for when a user uses a bashism that nu doesn't support. fixes #7237 Examples: ``` Error: nu::parser::shell_andand (link) × The '&&' operator is not supported in Nushell ╭─[entry #1:1:1] 1 │ ls && ls · ─┬ · ╰── instead of '&&', use ';' or 'and' ╰──── help: use ';' instead of the shell '&&', or 'and' instead of the boolean '&&' ``` ``` Error: nu::parser::shell_oror (link) × The '||' operator is not supported in Nushell ╭─[entry #8:1:1] 1 │ ls || ls · ─┬ · ╰── instead of '||', use 'try' or 'or' ╰──── help: use 'try' instead of the shell '||', or 'or' instead of the boolean '||' ``` ``` Error: nu::parser::shell_err (link) × The '2>' shell operation is 'err>' in Nushell. ╭─[entry #9:1:1] 1 │ foo 2> bar.txt · ─┬ · ╰── use 'err>' instead of '2>' in Nushell ╰──── ``` ``` Error: nu::parser::shell_outerr (link) × The '2>&1' shell operation is 'out+err>' in Nushell. ╭─[entry #10:1:1] 1 │ foo 2>&1 bar.txt · ──┬─ · ╰── use 'out+err>' instead of '2>&1' in Nushell ╰──── help: Nushell redirection will write all of stdout before stderr. ``` # User-Facing Changes **BREAKING CHANGES** This removes the `&&` and `||` operators. We previously supported by `&&`/`and` and `||`/`or`. With this change, only `and` and `or` are valid boolean operators. # 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 # 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.

Layout improvements

references (nushell#7)

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 ╰──── ```

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 ╰──── ```

# Description Fixes: #11451 # User-Facing Changes ### Before ```nushell ❯ [1 2 3] | each {|e| break; print $e } ╭────────────╮ │ empty list │ ╰────────────╯ ``` ### After ``` ❯ [1 2 3] | each {|e| break; print $e } Error: nu::shell::eval_block_with_input × Eval block failed with pipeline input ╭─[entry #9:1:2] 1 │ [1 2 3] | each {|e| break; print $e } · ┬ · ╰── source value ╰──── Error: × Break used outside of loop ╭─[entry #9:1:21] 1 │ [1 2 3] | each {|e| break; print $e } · ──┬── · ╰── used outside of loop ╰──── ``` # Tests + Formatting Removes some tests.

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

# Description The test is failed when updating miette from 7.2 to 7.3. After looking into the test, I think it's ok to adjust test. # User-Facing Changes For the given custom command: ```nushell def force_error [ x: any ] { error make { msg: "oh no!" label: { text: "here's the error" span: (metadata $x).span } } } ``` ### Before ``` > force_error "My error" Error: × oh no! ╭─[entry #8:1:13] 1 │ force_error "My error" · ─────┬──── · ╰── here's the error ╰──── ``` ### After ``` > force_error "My error" Error: × oh no! ╭─[entry #9:1:13] 1 │ force_error "My error" · ─────┬──── · ╰── here's the error ╰──── ``` As we can see, the message `oh no!` is output in a new line, and there is one less trailing line. I have makes some testing, and it seems that it only happened on `error make` command. # Tests + Formatting Changed 1 test # After Submitting NaN

# Description  This PR adds type checking of all command input types at run-time. Generally, these errors should be caught by the parser, but sometimes we can't know the type of a value at parse-time. The simplest example is using the `echo` command, which has an output type of `any`, so prefixing a literal with `echo` will bypass parse-time type checking. Before this PR, each command has to individually check its input types. This can result in scenarios where the input/output types don't match the actual command behavior. This can cause valid usage with an non-`any` type to become a parse-time error if a command is missing that type in its pipeline input/output (`drop nth` and `history import` do this before this PR). Alternatively, a command may not list a type in its input/output types, but doesn't actually reject that type in its code, which can have unintended side effects (`get` does this on an empty pipeline input, and `sort` used to before #13154). After this PR, the type of the pipeline input is checked to ensure it matches one of the input types listed in the proceeding command's input/output types. While each of the issues in the "before this PR" section could be addressed with each command individually, this PR solves this issue for _all_ commands. **This will likely cause some breakage**, as some commands have incorrect input/output types, and should be adjusted. Also, some scripts may have erroneous usage of commands. In writing this PR, I discovered that `toolkit.nu` was passing `null` values to `str join`, which doesn't accept nothing types (if folks think it should, we can adjust it in this PR or in a different PR). I found some issues in the standard library and its tests. I also found that carapace's vendor script had an incorrect chaining of `get -i`: ```nushell let expanded_alias = (scope aliases | where name == $spans.0 | get -i 0 | get -i expansion) ``` Before this PR, if the `get -i 0` ever actually did evaluate to `null`, the second `get` invocation would error since `get` doesn't operate on `null` values. After this PR, this is immediately a run-time error, alerting the user to the problematic code. As a side note, we'll need to PR this fix (`get -i 0 | get -i expansion` -> `get -i 0.expansion`) to carapace. A notable exception to the type checking is commands with input type of `nothing -> <type>`. In this case, any input type is allowed. This allows piping values into the command without an error being thrown. For example, `123 | echo $in` would be an error without this exception. Additionally, custom types bypass type checking (I believe this also happens during parsing, but not certain) I added a `is_subtype` method to `Value` and `PipelineData`. It functions slightly differently than `get_type().is_subtype()`, as noted in the doccomments. Notably, it respects structural typing of lists and tables. For example, the type of a value `[{a: 123} {a: 456, b: 789}]` is a subtype of `table<a: int>`, whereas the type returned by `Value::get_type` is a `list<any>`. Similarly, `PipelineData` has some special handling for `ListStream`s and `ByteStream`s. The latter was needed for this PR to work properly with external commands. Here's some examples. Before: ```nu 1..2 | drop nth 1 Error: nu::parser::input_type_mismatch × Command does not support range input. ╭─[entry #9:1:8] 1 │ 1..2 | drop nth 1 · ────┬─── · ╰── command doesn't support range input ╰──── echo 1..2 | drop nth 1 # => ╭───┬───╮ # => │ 0 │ 1 │ # => ╰───┴───╯ ``` After this PR, I've adjusted `drop nth`'s input/output types to accept range input. Before this PR, zip accepted any value despite not being listed in its input/output types. This caused different behavior depending on if you triggered a parse error or not: ```nushell 1 | zip [2] # => Error: nu::parser::input_type_mismatch # => # => × Command does not support int input. # => ╭─[entry #3:1:5] # => 1 │ 1 | zip [2] # => · ─┬─ # => · ╰── command doesn't support int input # => ╰──── echo 1 | zip [2] # => ╭───┬───────────╮ # => │ 0 │ ╭───┬───╮ │ # => │ │ │ 0 │ 1 │ │ # => │ │ │ 1 │ 2 │ │ # => │ │ ╰───┴───╯ │ # => ╰───┴───────────╯ ``` After this PR, it works the same in both cases. For cases like this, if we do decide we want `zip` or other commands to accept any input value, then we should explicitly add that to the input types. ```nushell 1 | zip [2] # => Error: nu::parser::input_type_mismatch # => # => × Command does not support int input. # => ╭─[entry #3:1:5] # => 1 │ 1 | zip [2] # => · ─┬─ # => · ╰── command doesn't support int input # => ╰──── echo 1 | zip [2] # => Error: nu:🐚:only_supports_this_input_type # => # => × Input type not supported. # => ╭─[entry #14:2:6] # => 2 │ echo 1 | zip [2] # => · ┬ ─┬─ # => · │ ╰── only list<any> and range input data is supported # => · ╰── input type: int # => ╰──── ``` # User-Facing Changes  **Breaking change**: The type of a command's input is now checked against the input/output types of that command at run-time. While these errors should mostly be caught at parse-time, in cases where they can't be detected at parse-time they will be caught at run-time instead. This applies to both internal commands and custom commands. Example function and corresponding parse-time error (same before and after PR): ```nushell def foo []: int -> nothing { print $"my cool int is ($in)" } 1 | foo # => my cool int is 1 "evil string" | foo # => Error: nu::parser::input_type_mismatch # => # => × Command does not support string input. # => ╭─[entry #16:1:17] # => 1 │ "evil string" | foo # => · ─┬─ # => · ╰── command doesn't support string input # => ╰──── # => ``` Before: ```nu echo "evil string" | foo # => my cool int is evil string ``` After: ```nu echo "evil string" | foo # => Error: nu:🐚:only_supports_this_input_type # => # => × Input type not supported. # => ╭─[entry #17:1:6] # => 1 │ echo "evil string" | foo # => · ──────┬────── ─┬─ # => · │ ╰── only int input data is supported # => · ╰── input type: string # => ╰──── ``` Known affected internal commands which erroneously accepted any type: * `str join` * `zip` * `reduce` # Tests + Formatting  - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting  * Play whack-a-mole with the commands and scripts this will inevitably break

…14765) # Description This PR removes the required positional argument from `run-external` and `exec` in favor of the rest arguments, meaning lists of external commands can be spread directly into `run-external` and `exec`. This does have the drawback of making calling `run-external` and `exec` with no arguments a run-time error rather than a parse error, but I don't imagine that is an issue. Before (for both `run-external` and `exec`): ```nushell run-external # => Error: nu::parser::missing_positional # => # => × Missing required positional argument. # => ╭─[entry #9:1:13] # => 1 │ run-external # => ╰──── # => help: Usage: run-external <command> ...(args) . Use `--help` for more # => information. let command = ["cat" "hello.txt"] run-external ...$command # => Error: nu::parser::missing_positional # => # => × Missing required positional argument. # => ╭─[entry #11:1:14] # => 1 │ run-external ...$command # => · ▲ # => · ╰── missing command # => ╰──── # => help: Usage: run-external <command> ...(args) . Use `--help` for more # => information. run-external ($command | first) ...($command | skip 1) # => hello world! ``` After (for both `run-external` and `exec`): ```nushell run-external # => Error: nu:🐚:missing_parameter # => # => × Missing parameter: no command given. # => ╭─[entry #2:1:1] # => 1 │ run-external # => · ──────┬───── # => · ╰── missing parameter: no command given # => ╰──── # => let command = ["cat" "hello.txt"] run-external ...$command # => hello world! ``` # User-Facing Changes Lists can now be spread directly into `run-external` and `exec`: ```nushell let command = [cat hello.txt] run-external ...$command # => hello world! ``` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting N/A

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.

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

Complete commands a bit better

1b50b5b

sophiajt merged commit 447356c into nushell:master May 18, 2019

sophiajt deleted the better_completions branch May 18, 2019 14:12

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

Merge pull request nushell#9 from Aloso/master

42e12d2

Layout improvements

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)

107295472 mentioned this pull request Nov 8, 2023

There is no problem in cmd execution, but it is wrong to use nushell parameter path. #10994

Closed

132ikl mentioned this pull request Jan 28, 2025

Different blocking behavior for start depending on platform #14947

Open

archqt mentioned this pull request Aug 1, 2025

ls *.txt doesn't work if no files #16313

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Complete commands a bit better #9

Complete commands a bit better #9

sophiajt commented May 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Complete commands a bit better #9

Complete commands a bit better #9

Conversation

sophiajt commented May 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant