Rename bat -> view #10

sophiajt · 2019-05-18T14:16:02Z

Rename the "bat" command to "view" to make it easier for people who don't know what bat is.

Value streams in value

# 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.

update README, documentation, installation, contribute, about

…8274) # Description Fixes: #7575 # User-Facing Changes Previously: ``` if❯ if false { "aaa" } else if $a { 'a' } Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #10:1:1] 1 │ if false { "aaa" } else if $a { 'a' } · ─┬ · ╰── expected block, closure or record ╰──── ``` After: ``` ❯ if false { "aaa" } else if $a { 'a' } Error: nu::parser::variable_not_found × Variable not found. ╭─[entry #1:1:1] 1 │ if false { "aaa" } else if $a { 'a' } · ─┬ · ╰── variable not found ╰──── ``` # 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.

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

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

@fdncred

…#13154) # Description Closes #12535 Implements sort-by functionality of #8322 Fixes sort-by part of #8667 This PR does two main things: add a new cell path and closure parameter to `sort-by`, and attempt to make Nushell's sorting behavior well-defined. ## `sort-by` features The `columns` parameter is replaced with a `comparator` parameter, which can be a cell path or a closure. Examples are from docs PR. 1. Cell paths The basic interactive usage of `sort-by` is the same. For example, `ls | sort-by modified` still works the same as before. It is not quite a drop-in replacement, see [behavior changes](#behavior-changes). Here's an example of how the cell path comparator might be useful: ```nu > let cities = [ {name: 'New York', info: { established: 1624, population: 18_819_000 } } {name: 'Kyoto', info: { established: 794, population: 37_468_000 } } {name: 'São Paulo', info: { established: 1554, population: 21_650_000 } } ] > $cities | sort-by info.established ╭───┬───────────┬────────────────────────────╮ │ # │ name │ info │ ├───┼───────────┼────────────────────────────┤ │ 0 │ Kyoto │ ╭─────────────┬──────────╮ │ │ │ │ │ established │ 794 │ │ │ │ │ │ population │ 37468000 │ │ │ │ │ ╰─────────────┴──────────╯ │ │ 1 │ São Paulo │ ╭─────────────┬──────────╮ │ │ │ │ │ established │ 1554 │ │ │ │ │ │ population │ 21650000 │ │ │ │ │ ╰─────────────┴──────────╯ │ │ 2 │ New York │ ╭─────────────┬──────────╮ │ │ │ │ │ established │ 1624 │ │ │ │ │ │ population │ 18819000 │ │ │ │ │ ╰─────────────┴──────────╯ │ ╰───┴───────────┴────────────────────────────╯ ``` 2. Key closures You can supply a closure which will transform each value into a sorting key (without changing the underlying data). Here's an example of a key closure, where we want to sort a list of assignments by their average grade: ```nu > let assignments = [ {name: 'Homework 1', grades: [97 89 86 92 89] } {name: 'Homework 2', grades: [91 100 60 82 91] } {name: 'Exam 1', grades: [78 88 78 53 90] } {name: 'Project', grades: [92 81 82 84 83] } ] > $assignments | sort-by { get grades | math avg } ╭───┬────────────┬───────────────────────╮ │ # │ name │ grades │ ├───┼────────────┼───────────────────────┤ │ 0 │ Exam 1 │ [78, 88, 78, 53, 90] │ │ 1 │ Project │ [92, 81, 82, 84, 83] │ │ 2 │ Homework 2 │ [91, 100, 60, 82, 91] │ │ 3 │ Homework 1 │ [97, 89, 86, 92, 89] │ ╰───┴────────────┴───────────────────────╯ ``` 3. Custom sort closure The `--custom`, or `-c`, flag will tell `sort-by` to interpret closures as custom sort closures. A custom sort closure has two parameters, and returns a boolean. The closure should return `true` if the first parameter comes _before_ the second parameter in the sort order. For a simple example, we could rewrite a cell path sort as a custom sort (see [here](https://github.com/nushell/nushell.github.io/pull/1568/files#diff-a7a233e66a361d8665caf3887eb71d4288000001f401670c72b95cc23a948e86R231) for a more complex example): ```nu > ls | sort-by -c {|a, b| $a.size < $b.size } ╭───┬─────────────────────┬──────┬──────────┬────────────────╮ │ # │ name │ type │ size │ modified │ ├───┼─────────────────────┼──────┼──────────┼────────────────┤ │ 0 │ my-secret-plans.txt │ file │ 100 B │ 10 minutes ago │ │ 1 │ shopping_list.txt │ file │ 100 B │ 2 months ago │ │ 2 │ myscript.nu │ file │ 1.1 KiB │ 2 weeks ago │ │ 3 │ bigfile.img │ file │ 10.0 MiB │ 3 weeks ago │ ╰───┴─────────────────────┴──────┴──────────┴────────────────╯ ``` ## Making sort more consistent I think it's important for something as essential as `sort` to have well-defined semantics. This PR contains some changes to try to make the behavior of `sort` and `sort-by` consistent. In addition, after working with the internals of sorting code, I have a much deeper understanding of all of the edge cases. Here is my attempt to try to better define some of the semantics of sorting (if you are just interested in changes, skip to "User-Facing changes") - `sort`, `sort -v`, and `sort-by` now all work the same. Each individual sort implementation has been refactored into two functions in `sort_utils.rs`: `sort`, and `sort_by`. These can also be used in other parts of Nushell where values need to be sorted. - `sort` and `sort-by` used to handle `-i` and `-n` differently. - `sort -n` would consider all values which can't be coerced into a string to be equal - `sort-by -i` and `sort-by -n` would only work if all values were strings - In this PR, insensitive sort only affects comparison between strings, and natural sort only applies to numbers and strings (see below). - (not a change) Before and after this PR, `sort` and `sort-by` support sorting mixed types. There was a lot of discussion about potentially making `sort` and `sort-by` only work on lists of homogeneous types, but the general consensus was that `sort` should not error just because its input contains incompatible types. - In order to try to make working with data containing `null` values easier, I changed the PartialOrd order to sort `Nothing` values to the end of a list, regardless of what other types the list contains. Before, `null` would be sorted before `Binary`, `CellPath`, and `Custom` values. - (not a change) When sorted, lists of mixed types will contain sorted values of each type in order, for the most part - (not a change) For example, `[0x[1] (date now) "a" ("yesterday" | into datetime) "b" 0x[0]]` will be sorted as `["a", "b", a day ago, now, [0], [1]]`, where sorted strings appear first, then sorted datetimes, etc. - (not a change) The exception to this is `Int`s and `Float`s, which will intermix, `Strings` and `Glob`s, which will intermix, and `None` as described above. Additionally, natural sort will intermix strings with ints and floats (see below). - Natural sort no longer coerce all inputs to strings. - I did originally make natural only apply to strings, but @fdncred pointed out that the previous behavior also allowed you to sort numeric strings with numbers. This seems like a useful feature if we are trying to support sorting with mixed types, so I settled on coercing only numbers (int, float). This can be reverted if people don't like it. - Here is an example of this behavior in action, which is the same before and after this PR: ```nushell $ [1 "4" 3 "2"] | sort --natural ╭───┬───╮ │ 0 │ 1 │ │ 1 │ 2 │ │ 2 │ 3 │ │ 3 │ 4 │ ╰───┴───╯ ``` # User-Facing Changes ## New features - Replaces the `columns` string parameter of `sort-by` with a cell path or a closure. - The cell path parameter works exactly as you would expect - By default, the `closure` parameter acts as a "key sort"; that is, each element is transformed by the closure into a sorting key - With the `--custom` (`-c`) parameter, you can define a comparison function for completely custom sorting order. ## Behavior changes <details> <summary><code>sort -v</code> does not coerce record values to strings</summary> This was a bit of a surprising behavior, and is now unified with the behavior of `sort` and `sort-by`. Here's an example where you can observe the values being implicitly coerced into strings for sorting, as they are sorted like strings rather than numbers: Old behavior: ```nushell $ {foo: 9 bar: 10} | sort -v ╭─────┬────╮ │ bar │ 10 │ │ foo │ 9 │ ╰─────┴────╯ ``` New behavior: ```nushell $ {foo: 9 bar: 10} | sort -v ╭─────┬────╮ │ foo │ 9 │ │ bar │ 10 │ ╰─────┴────╯ ``` </details> <details> <summary>Changed <code>sort-by</code> parameters from <code>string</code> to <code>cell-path</code> or <code>closure</code>. Typical interactive usage is the same as before, but if passing a variable to <code>sort-by</code> it must be a cell path (or closure), not a string</summary> Old behavior: ```nushell $ let sort = "modified" $ ls | sort-by $sort ╭───┬──────┬──────┬──────┬────────────────╮ │ # │ name │ type │ size │ modified │ ├───┼──────┼──────┼──────┼────────────────┤ │ 0 │ foo │ file │ 0 B │ 10 hours ago │ │ 1 │ bar │ file │ 0 B │ 35 seconds ago │ ╰───┴──────┴──────┴──────┴────────────────╯ ``` New behavior: ```nushell $ let sort = "modified" $ ls | sort-by $sort Error: nu::shell::type_mismatch × Type mismatch. ╭─[entry #10:1:14] 1 │ ls | sort-by $sort · ──┬── · ╰── Cannot sort using a value which is not a cell path or closure ╰──── $ let sort = $."modified" $ ls | sort-by $sort ╭───┬──────┬──────┬──────┬───────────────╮ │ # │ name │ type │ size │ modified │ ├───┼──────┼──────┼──────┼───────────────┤ │ 0 │ foo │ file │ 0 B │ 10 hours ago │ │ 1 │ bar │ file │ 0 B │ 2 minutes ago │ ╰───┴──────┴──────┴──────┴───────────────╯ ``` </details> <details> <summary>Insensitve and natural sorting behavior reworked</summary> Previously, the `-i` and `-n` worked differently for `sort` and `sort-by` (see "Making sort more consistent"). Here are examples of how these options result in different sorts now: 1. `sort -n` - Old behavior (types other than numbers, strings, dates, and binary sorted incorrectly) ```nushell $ [2sec 1sec] | sort -n ╭───┬──────╮ │ 0 │ 2sec │ │ 1 │ 1sec │ ╰───┴──────╯ ``` - New behavior ```nushell $ [2sec 1sec] | sort -n ╭───┬──────╮ │ 0 │ 1sec │ │ 1 │ 2sec │ ╰───┴──────╯ ``` 2. `sort-by -i` - Old behavior (uppercase words appear before lowercase words as they would in a typical sort, indicating this is not actually an insensitive sort) ```nushell $ ["BAR" "bar" "foo" 2 "FOO" 1] | wrap a | sort-by -i a ╭───┬─────╮ │ # │ a │ ├───┼─────┤ │ 0 │ 1 │ │ 1 │ 2 │ │ 2 │ BAR │ │ 3 │ FOO │ │ 4 │ bar │ │ 5 │ foo │ ╰───┴─────╯ ``` - New behavior (strings are sorted stably, indicating this is an insensitive sort) ```nushell $ ["BAR" "bar" "foo" 2 "FOO" 1] | wrap a | sort-by -i a ╭───┬─────╮ │ # │ a │ ├───┼─────┤ │ 0 │ 1 │ │ 1 │ 2 │ │ 2 │ BAR │ │ 3 │ bar │ │ 4 │ foo │ │ 5 │ FOO │ ╰───┴─────╯ ``` 3. `sort-by -n` - Old behavior (natural sort does not work when data contains non-string values) ```nushell $ ["10" 8 "9"] | wrap a | sort-by -n a ╭───┬────╮ │ # │ a │ ├───┼────┤ │ 0 │ 8 │ │ 1 │ 10 │ │ 2 │ 9 │ ╰───┴────╯ ``` - New behavior ```nushell $ ["10" 8 "9"] | wrap a | sort-by -n a ╭───┬────╮ │ # │ a │ ├───┼────┤ │ 0 │ 8 │ │ 1 │ 9 │ │ 2 │ 10 │ ╰───┴────╯ ``` </details> <details> <summary> Sorting a list of non-record values with a non-existent column/path now errors instead of sorting the values directly (<code>sort</code> should be used for this, not <code>sort-by</code>) </summary> Old behavior: ```nushell $ [2 1] | sort-by foo ╭───┬───╮ │ 0 │ 1 │ │ 1 │ 2 │ ╰───┴───╯ ``` New behavior: ```nushell $ [2 1] | sort-by foo Error: nu:🐚:incompatible_path_access × Data cannot be accessed with a cell path ╭─[entry #29:1:17] 1 │ [2 1] | sort-by foo · ─┬─ · ╰── int doesn't support cell paths ╰──── ``` </details> <details> <summary><code>sort</code> and <code>sort-by</code> output <code>List</code> instead of <code>ListStream</code> </summary> This isn't a meaningful change (unless I misunderstand the purpose of ListStream), since `sort` and `sort-by` both need to collect in order to do the sorting anyway, but is user observable. Old behavior: ```nushell $ ls | sort | describe -d ╭──────────┬───────────────────╮ │ type │ stream │ │ origin │ nushell │ │ subtype │ {record 3 fields} │ │ metadata │ {record 1 field} │ ╰──────────┴───────────────────╯ ``` ```nushell $ ls | sort-by name | describe -d ╭──────────┬───────────────────╮ │ type │ stream │ │ origin │ nushell │ │ subtype │ {record 3 fields} │ │ metadata │ {record 1 field} │ ╰──────────┴───────────────────╯ ``` New behavior: ```nushell ls | sort | describe -d ╭────────┬─────────────────╮ │ type │ list │ │ length │ 22 │ │ values │ [table 22 rows] │ ╰────────┴─────────────────╯ ``` ```nushell $ ls | sort-by name | describe -d ╭────────┬─────────────────╮ │ type │ list │ │ length │ 22 │ │ values │ [table 22 rows] │ ╰────────┴─────────────────╯ ``` </details> - `sort` now errors when nothing is piped in (`sort-by` already did this) # Tests + Formatting I added lots of unit tests on the new sort implementation to enforce new sort behaviors and prevent regressions. # After Submitting See [docs PR](nushell/nushell.github.io#1568), which is ~2/3 finished. --------- Co-authored-by: NotTheDr01ds <[email protected]> Co-authored-by: Ian Manske <[email protected]>

…m the declaration (#14490) # Description Before this PR, `help commands` uses the name from a command's declaration rather than the name in the scope. This is problematic when trying to view the help page for the `main` command of a module. For example, `std bench`: ```nushell use std/bench help bench # => Error: nu::parser::not_found # => # => × Not found. # => ╭─[entry #10:1:6] # => 1 │ help bench # => · ──┬── # => · ╰── did not find anything under this name # => ╰──── ``` This can also cause confusion when importing specific commands from modules. Furthermore, if there are multiple commands with the same name from different modules, the help text for _both_ will appear when querying their help text (this is especially problematic for `main` commands, see #14033): ```nushell use std/iter help iter find # => Error: nu::parser::not_found # => # => × Not found. # => ╭─[entry #3:1:6] # => 1│ help iter find # => · ────┬──── # => · ╰── did not find anything under this name # => ╰──── help find # => Searches terms in the input. # => # => Search terms: filter, regex, search, condition # => # => Usage: # => > find {flags} ...(rest) # [...] # => Returns the first element of the list that matches the # => closure predicate, `null` otherwise # [...] # (full text omitted for brevity) ``` This PR changes `help commands` to use the name as it is in scope, so prefixing any command in scope with `help` will show the correct help text. ```nushell use std/bench help bench # [help text for std bench] use std/iter help iter find # [help text for std iter find] use std help std bench # [help text for std bench] help std iter find # [help text for std iter find] ``` Additionally, the IR code generation for commands called with the `--help` text has been updated to reflect this change. This does have one side effect: when a module has a `main` command defined, running `help <name>` (which checks `help aliases`, then `help commands`, then `help modules`) will show the help text for the `main` command rather than the module. The help text for the module is still accessible with `help modules <name>`. Fixes #10499, #10311, #11609, #13470, #14033, and #14402. Partially fixes #10707. Does **not** fix #11447. # User-Facing Changes * Help text for commands can be obtained by running `help <command name>`, where the command name is the same thing you would type in order to execute the command. Previously, it was the name of the function as written in the source file. * For example, for the following module `spam` with command `meow`: ```nushell module spam { # help text export def meow [] {} } ``` * Before this PR: * Regardless of how `meow` is `use`d, the help text is viewable by running `help meow`. * After this PR: * When imported with `use spam`: The `meow` command is executed by running `spam meow` and the `help` text is viewable by running `help spam meow`. * When imported with `use spam foo`: The `meow` command is executed by running `meow` and the `help` text is viewable by running `meow`. * When a module has a `main` command defined, `help <module name>` will return help for the main command, rather than the module. To access the help for the module, use `help modules <module name>`. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting N/A

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

Rename bat -> view

2e2831d

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

sophiajt deleted the view branch May 18, 2019 14:16

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

Implement several new commands (nushell#10)

24e890f

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

Merge pull request nushell#10 from jntrnr/value_streams_in_value

bc3f820

Value streams in value

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

Merge pull request nushell#10 from sebastian-xyz/master

6d170a5

update README, documentation, installation, contribute, about

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

Add default links for non-translated content in nav (nushell#10)

20c1dae

hustcer pushed a commit to hustcer/nushell that referenced this pull request Oct 22, 2024

Removes mimalloc from riscv64gc and armv7 (nushell#10)

6e2f968

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

Uh oh!

Rename bat -> view #10

Rename bat -> view #10

Uh oh!

sophiajt commented May 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Rename bat -> view #10

Rename bat -> view #10

Uh oh!

Conversation

sophiajt commented May 18, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant