Add support for skip and where #1

sophiajt · 2019-05-16T02:43:53Z

Adds initial support for where and skip.

Newbra

* ci(github): lowercase ${{ github.actor }} * ci(github): fix robot username * fix(ci): fix tag name on suffixed version

Implement primitive word-jumping

Removed file_id in Span, compact file sources

# Description BEFORE: ``` 〉ls | size Error: nu::shell::pipeline_mismatch (link) × Pipeline mismatch. ╭─[entry #22:1:1] 1 │ ls | size · ──┬─ · │╰── value originates from here · ╰── expected: string ╰──── 〉ls | sort-by SIZE Error: nu:🐚:column_not_found (link) × Cannot find column ╭─[entry #17:1:1] 1 │ ls | sort-by SIZE · ───┬─── · │╰── value originates here · ╰── cannot find column ╰──── 〉[4kb] | path join 'b' Error: nu:🐚:pipeline_mismatch (link) × Pipeline mismatch. ╭─[entry #6:1:1] 1 │ [4kb] | path join 'b' · ──┬── · │╰── value originates from here · ╰── expected: string or record ╰──── ``` AFTER: ``` 〉ls | size Error: nu:🐚:pipeline_mismatch (link) × Pipeline mismatch. ╭─[entry #1:1:1] 1 │ ls | size · ─┬ ──┬─ · │ ╰── expected: string · ╰── value originates from here ╰──── 〉ls | get 0 | sort-by SIZE Error: nu:🐚:column_not_found (link) × Cannot find column ╭─[entry #2:1:1] 1 │ ls | get 0 | sort-by SIZE · ─┬ ───┬─── · │ ╰── cannot find column 'SIZE' · ╰── value originates here ╰──── 〉[4kb] | path join 'b' Error: nu:🐚:pipeline_mismatch (link) × Pipeline mismatch. ╭─[entry #1:1:1] 1 │ [4kb] | path join 'b' · ──┬── ────┬──── · │ ╰── expected: string or record · ╰── value originates from here ╰──── ``` (Hey, anyone noticed that there's TWO wordings of "value originates from here" in this codebase………?) # User-Facing Changes See above. # 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 --features=extra -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` to check that you're using the standard code style - `cargo test --workspace --features=extra` 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.

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

# Description Fixes #7407. ``` /home/gabriel/CodingProjects/nushell〉if false { 'a' } else { $foo } 12/09/2022 08:14:48 PM Error: nu::parser::variable_not_found (link) × Variable not found. ╭─[entry #1:1:1] 1 │ if false { 'a' } else { $foo } · ──┬─ · ╰── variable not found ╰──── ``` # User-Facing Changes _(List of all changes that impact the user experience here. This helps us keep track of breaking changes.)_ # Tests + Formatting Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` 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.

@Kangaxx-0

# Description Closes #7059. Rather than generate a new Record each time $env.config is accessed (as described in that issue), instead `$env.config = ` now A) parses the input record, then B) un-parses it into a clean Record with only the valid values, and stores that as an env-var. The reasoning for this is that I believe `config_to_nu_record()` (the method that performs step B) will be useful in later PRs. (See below) As a result, this also "fixes" the following "bug": ``` 〉$env.config = 'butts' $env.config is not a record 〉$env.config butts ``` ~~Instead, `$env.config = 'butts'` now turns `$env.config` into the default (not the default config.nu, but `Config::default()`, which notably has empty keybindings, color_config, menus and hooks vecs).~~ This doesn't attempt to fix #7110. cc @Kangaxx-0 # Example of new behaviour OLD: ``` 〉$env.config = ($env.config | merge { foo: 1 }) $env.config.foo is an unknown config setting 〉$env.config.foo 1 ``` NEW: ``` 〉$env.config = ($env.config | merge { foo: 1 }) Error: × Config record contains invalid values or unknown settings Error: × Error while applying config changes ╭─[entry #1:1:1] 1 │ $env.config = ($env.config | merge { foo: 1 }) · ┬ · ╰── $env.config.foo is an unknown config setting ╰──── help: This value has been removed from your $env.config record. 〉$env.config.foo Error: nu:🐚:column_not_found (link) × Cannot find column ╭─[entry #1:1:1] 1 │ $env.config = ($env.config | merge { foo: 1 }) · ──┬── · ╰── value originates here ╰──── ╭─[entry #2:1:1] 1 │ $env.config.foo · ─┬─ · ╰── cannot find column 'foo' ╰──── ``` # Example of new errors OLD: ``` $env.config.cd.baz is an unknown config setting $env.config.foo is an unknown config setting $env.config.bar is an unknown config setting $env.config.table.qux is an unknown config setting $env.config.history.qux is an unknown config setting ``` NEW: ``` Error: × Config record contains invalid values or unknown settings Error: × Error while applying config changes ╭─[C:\Users\Leon\AppData\Roaming\nushell\config.nu:267:1] 267 │ abbreviations: true # allows `cd s/o/f` to expand to `cd some/other/folder` 268 │ baz: 3, · ┬ · ╰── $env.config.cd.baz is an unknown config setting 269 │ } ╰──── help: This value has been removed from your $env.config record. Error: × Error while applying config changes ╭─[C:\Users\Leon\AppData\Roaming\nushell\config.nu:269:1] 269 │ } 270 │ foo: 1, · ┬ · ╰── $env.config.foo is an unknown config setting 271 │ bar: 2, ╰──── help: This value has been removed from your $env.config record. Error: × Error while applying config changes ╭─[C:\Users\Leon\AppData\Roaming\nushell\config.nu:270:1] 270 │ foo: 1, 271 │ bar: 2, · ┬ · ╰── $env.config.bar is an unknown config setting ╰──── help: This value has been removed from your $env.config record. Error: × Error while applying config changes ╭─[C:\Users\Leon\AppData\Roaming\nushell\config.nu:279:1] 279 │ } 280 │ qux: 4, · ┬ · ╰── $env.config.table.qux is an unknown config setting 281 │ } ╰──── help: This value has been removed from your $env.config record. Error: × Error while applying config changes ╭─[C:\Users\Leon\AppData\Roaming\nushell\config.nu:285:1] 285 │ file_format: "plaintext" # "sqlite" or "plaintext" 286 │ qux: 2 · ┬ · ╰── $env.config.history.qux is an unknown config setting 287 │ } ╰──── help: This value has been removed from your $env.config record. ``` # User-Facing Changes See above. # 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.

# Description Fixes #6773. ``` /home/gabriel/CodingProjects/nushell〉ls -r 12/12/2022 02:57:35 PM Error: nu::parser::unknown_flag (link) × The `ls` command doesn't have flag `-r`. ╭─[entry #1:1:1] 1 │ ls -r · ┬ · ╰── unknown flag ╰──── help: Available flags: --help(-h), --all(-a), --long(-l), --short-names(-s), --full-paths(-f), --du(-d), --directory(-D). Use `--help` for more information. ``` # User-Facing Changes Different error for unknown flag. # 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.

# Description Fixes #7494. ``` /home/gabriel/CodingProjects/nushell〉[[{foo: bar}]] | get foo 12/16/2022 12:31:17 PM Error: nu::parser::not_found (link) × Not found. ╭─[entry #1:1:1] 1 │ [[{foo: bar}]] | get foo · ───────┬────── · ╰── did not find anything under this name ╰──── ``` # User-Facing Changes cell paths no longer drill into nested tables. # 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.

…ypeMismatch and add spans to every instance of the former (#7217) # Description * I was dismayed to discover recently that UnsupportedInput and TypeMismatch are used *extremely* inconsistently across the codebase. UnsupportedInput is sometimes used for input type-checks (as per the name!!), but *also* used for argument type-checks. TypeMismatch is also used for both. I thus devised the following standard: input type-checking *only* uses UnsupportedInput, and argument type-checking *only* uses TypeMismatch. Moreover, to differentiate them, UnsupportedInput now has *two* error arrows (spans), one pointing at the command and the other at the input origin, while TypeMismatch only has the one (because the command should always be nearby) * In order to apply that standard, a very large number of UnsupportedInput uses were changed so that the input's span could be retrieved and delivered to it. * Additionally, I noticed many places where **errors are not propagated correctly**: there are lots of `match` sites which take a Value::Error, then throw it away and replace it with a new Value::Error with less/misleading information (such as reporting the error as an "incorrect type"). I believe that the earliest errors are the most important, and should always be propagated where possible. * Also, to standardise one broad subset of UnsupportedInput error messages, who all used slightly different wordings of "expected `<type>`, got `<type>`", I created OnlySupportsThisInputType as a variant of it. * Finally, a bunch of error sites that had "repeated spans" - i.e. where an error expected two spans, but `call.head` was given for both - were fixed to use different spans. # Example BEFORE ``` 〉20b | str starts-with 'a' Error: nu::shell::unsupported_input (link) × Unsupported input ╭─[entry #31:1:1] 1 │ 20b | str starts-with 'a' · ┬ · ╰── Input's type is filesize. This command only works with strings. ╰──── 〉'a' | math cos Error: nu:🐚:unsupported_input (link) × Unsupported input ╭─[entry #33:1:1] 1 │ 'a' | math cos · ─┬─ · ╰── Only numerical values are supported, input type: String ╰──── 〉0x[12] | encode utf8 Error: nu:🐚:unsupported_input (link) × Unsupported input ╭─[entry #38:1:1] 1 │ 0x[12] | encode utf8 · ───┬── · ╰── non-string input ╰──── ``` AFTER ``` 〉20b | str starts-with 'a' Error: nu:🐚:pipeline_mismatch (link) × Pipeline mismatch. ╭─[entry #1:1:1] 1 │ 20b | str starts-with 'a' · ┬ ───────┬─────── · │ ╰── only string input data is supported · ╰── input type: filesize ╰──── 〉'a' | math cos Error: nu:🐚:pipeline_mismatch (link) × Pipeline mismatch. ╭─[entry #2:1:1] 1 │ 'a' | math cos · ─┬─ ────┬─── · │ ╰── only numeric input data is supported · ╰── input type: string ╰──── 〉0x[12] | encode utf8 Error: nu:🐚:pipeline_mismatch (link) × Pipeline mismatch. ╭─[entry #3:1:1] 1 │ 0x[12] | encode utf8 · ───┬── ───┬── · │ ╰── only string input data is supported · ╰── input type: binary ╰──── ``` # User-Facing Changes Various error messages suddenly make more sense (i.e. have two arrows instead of one). # 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.

To properly use `ShellError::PipelineMismatch` in `PipelineData::collect_string_strict()`, `ListStream` needs to carry a `Span` as well. Introduces the `span` field on `ListStream` and adjusts the respective `.into_pipeline_data(.*)` methods. Requires changes to many commands. This change directly improves the `from ...` error messages: Before: ``` /home/stefan/nushell: {a:1 b:2} | from nuon Error: nu::shell::type_mismatch (link) × Type mismatch ╭─[entry nushell#1:1:1] 1 │ {a:1 b:2} | from nuon · ────┬──── · ╰── needs string ╰──── ``` After: ``` /home/stefan/nushell: {a:1 b:2} | from nuon Error: nu:🐚:pipeline_mismatch (link) × Pipeline mismatch. ╭─[entry nushell#1:1:1] 1 │ {a:1 b:2} | from nuon · ────┬──── ────┬──── · │ ╰── expected: string · ╰── value originates from here ╰──── ```

…nt on #7002) (#7647) # Description This closes #7498, as well as fixes an issue reported in #7002 (comment) BEFORE: ``` 〉[{foo: 'bar'} {}] | get foo Error: nu::shell::column_not_found (link) × Cannot find column ╭─[entry #5:1:1] 1 │ [{foo: 'bar'} {}] | get foo · ────────┬──────── ─┬─ · │ ╰── value originates here · ╰── cannot find column 'Empty cell' ╰──── 〉[{foo: 'bar'} {}].foo ╭───┬─────╮ │ 0 │ bar │ │ 1 │ │ ╰───┴─────╯ ``` AFTER: ``` 〉[{foo: 'bar'} {}] | get foo Error: nu:🐚:column_not_found (link) × Cannot find column ╭─[entry #1:1:1] 1 │ [{foo: 'bar'} {}] | get foo · ─┬ ─┬─ · │ ╰── cannot find column 'foo' · ╰── value originates here ╰──── 〉[{foo: 'bar'} {}].foo Error: nu:🐚:column_not_found (link) × Cannot find column ╭─[entry #3:1:1] 1 │ [{foo: 'bar'} {}].foo · ─┬ ─┬─ · │ ╰── cannot find column 'foo' · ╰── value originates here ╰──── ``` EDIT: This also changes the semantics of `get`/`select` `-i` somewhat. I've decided to leave it like this because it works more intuitively with `default` and `compact`. BEFORE: ``` 〉[{a:1} {b:2} {a:3}] | select -i foo | to nuon null ``` AFTER: ``` 〉[{a:1} {b:2} {a:3}] | select -i foo | to nuon [[foo]; [null], [null], [null]] ``` # User-Facing Changes See above. EDIT: the issue with holes in cases like ` [{foo: 'bar'} {}].foo.0` versus ` [{foo: 'bar'} {}].0.foo` has been resolved. # 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.

a first design test

Initial draft of website

# Description This PR will help report a bad date that can't be converted where the error message says `* Unable to parse datetime`. This is helpful when you're converting a big table and it fails somewhere that you really can't see. I put it in `[]` so that when it's null, you can see that there should be something there. Before: ``` > 'Tue 1 0' | into datetime Error: nu::shell::datetime_parse_error (link) × Unable to parse datetime ╭─[entry #1:1:1] 1 │ 'Tue 1 0' | into datetime · ────┬──── · ╰── datetime parsing failed ╰──── help: Examples of supported inputs: * "5 pm" * "2020/12/4" * "2020.12.04 22:10 +2" * "2020-04-12 22:10:57 +02:00" * "2020-04-12T22:10:57.213231+02:00" * "Tue, 1 Jul 2003 10:52:37 +0200" ``` After: ``` > 'Tue 1 0' | into datetime Error: nu:🐚:datetime_parse_error (link) × Unable to parse datetime: [Tue 1 0]. ╭─[entry #4:1:1] 1 │ 'Tue 1 0' | into datetime · ────┬──── · ╰── datetime parsing failed ╰──── help: Examples of supported inputs: * "5 pm" * "2020/12/4" * "2020.12.04 22:10 +2" * "2020-04-12 22:10:57 +02:00" * "2020-04-12T22:10:57.213231+02:00" * "Tue, 1 Jul 2003 10:52:37 +0200" ``` # User-Facing Changes New format for the error message. # 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.

# Description This PR will help report a bad date that can't be converted where the error message says `* Unable to parse datetime`. This is helpful when you're converting a big table and it fails somewhere that you really can't see. I put it in `[]` so that when it's null, you can see that there should be something there. Before: ``` > 'Tue 1 0' | into datetime Error: nu::shell::datetime_parse_error (link) × Unable to parse datetime ╭─[entry nushell#1:1:1] 1 │ 'Tue 1 0' | into datetime · ────┬──── · ╰── datetime parsing failed ╰──── help: Examples of supported inputs: * "5 pm" * "2020/12/4" * "2020.12.04 22:10 +2" * "2020-04-12 22:10:57 +02:00" * "2020-04-12T22:10:57.213231+02:00" * "Tue, 1 Jul 2003 10:52:37 +0200" ``` After: ``` > 'Tue 1 0' | into datetime Error: nu:🐚:datetime_parse_error (link) × Unable to parse datetime: [Tue 1 0]. ╭─[entry nushell#4:1:1] 1 │ 'Tue 1 0' | into datetime · ────┬──── · ╰── datetime parsing failed ╰──── help: Examples of supported inputs: * "5 pm" * "2020/12/4" * "2020.12.04 22:10 +2" * "2020-04-12 22:10:57 +02:00" * "2020-04-12T22:10:57.213231+02:00" * "Tue, 1 Jul 2003 10:52:37 +0200" ``` # User-Facing Changes New format for the error message. # 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.

# Description This PR does the following: 1. Adds a new command called `view span` - which shows what is at the location of the span parameters 2. Adds a new command called `view` - which just lists all the `view` commands. 3. Renames `view-source` to `view source`. 4. Adds a new command called `view files` - which shows you what files are loaded into nushell's EngineState memory. 5. Added a `Category::Debug` and put these commands (and others) into it. (`inspect` needs to be added to it, but it's not landed yet) Spans are important to nushell. One of their uses is to show where errors are. For instance, in this example, the leader lines pointing to parts of the command line are able to point to `10`, `/`, and `"bob"` because each of those items have a span. ``` > 10 / "bob" Error: nu::parser::unsupported_operation (link) × Types mismatched for operation. ╭─[entry #8:1:1] 1 │ 10 / "bob" · ─┬ ┬ ──┬── · │ │ ╰── string · │ ╰── doesn't support these values. · ╰── int ╰──── help: Change int or string to be the right types and try again. ``` # Examples ## view span Example: ``` > $env.config | get keybindings | first | debug -r ... bunch of stuff span: Span { start: 68065, end: 68090, }, }, ], span: Span { start: 68050, end: 68101, }, }, ], span: Span { start: 67927, end: 68108, }, } ``` To view the last span: ``` > view span 67927 68108 { name: clear_everything modifier: control keycode: char_l mode: emacs event: [ { send: clearscrollback } ] } ``` > To view the 2nd to last span: ``` view span 68065 68090 { send: clearscrollback } ``` > To view the 3rd to last span: ``` view span 68050 68101 [ { send: clearscrollback } ] ``` ## view files ``` > view files ╭────┬───────────────────────────────────────────────────────┬────────┬────────┬───────╮ │ # │ filename │ start │ end │ size │ ├────┼───────────────────────────────────────────────────────┼────────┼────────┼───────┤ │ 0 │ source │ 0 │ 2 │ 2 │ │ 1 │ Host Environment Variables │ 2 │ 6034 │ 6032 │ │ 2 │ C:\Users\a_username\AppData\Roaming\nushell\plugin.nu │ 6034 │ 31236 │ 25202 │ │ 3 │ C:\Users\a_username\AppData\Roaming\nushell\env.nu │ 31236 │ 44961 │ 13725 │ │ 4 │ C:\Users\a_username\AppData\Roaming\nushell\config.nu │ 44961 │ 76134 │ 31173 │ │ 5 │ defs.nu │ 76134 │ 91944 │ 15810 │ │ 6 │ prompt\oh-my.nu │ 91944 │ 111523 │ 19579 │ │ 7 │ weather\get-weather.nu │ 111523 │ 125556 │ 14033 │ │ 8 │ .zoxide.nu │ 125556 │ 127504 │ 1948 │ │ 9 │ source │ 127504 │ 127561 │ 57 │ │ 10 │ entry #1 │ 127561 │ 127585 │ 24 │ │ 11 │ entry #2 │ 127585 │ 127595 │ 10 │ ╰────┴───────────────────────────────────────────────────────┴────────┴────────┴───────╯ ``` `entry #x` will be each command you type in the repl (i think). so, it may be good to filter those out sometimes. ``` > view files | where filename !~ entry ╭───┬───────────────────────────────────────────────────────┬────────┬────────┬───────╮ │ # │ filename │ start │ end │ size │ ├───┼───────────────────────────────────────────────────────┼────────┼────────┼───────┤ │ 0 │ source │ 0 │ 2 │ 2 │ │ 1 │ Host Environment Variables │ 2 │ 6034 │ 6032 │ │ 2 │ C:\Users\a_username\AppData\Roaming\nushell\plugin.nu │ 6034 │ 31236 │ 25202 │ │ 3 │ C:\Users\a_username\AppData\Roaming\nushell\env.nu │ 31236 │ 44961 │ 13725 │ │ 4 │ C:\Users\a_username\AppData\Roaming\nushell\config.nu │ 44961 │ 76134 │ 31173 │ │ 5 │ defs.nu │ 76134 │ 91944 │ 15810 │ │ 6 │ prompt\oh-my.nu │ 91944 │ 111523 │ 19579 │ │ 7 │ weather\get-weather.nu │ 111523 │ 125556 │ 14033 │ │ 8 │ .zoxide.nu │ 125556 │ 127504 │ 1948 │ │ 9 │ source │ 127504 │ 127561 │ 57 │ ╰───┴───────────────────────────────────────────────────────┴────────┴────────┴───────╯ ``` # User-Facing Changes I renamed `view-source` to `view source` just to make a group of commands. No functionality has changed in `view source`. # 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.

# Description This PR adds a deprecated message to the `benchmark` command. ``` > benchmark Error: nu::shell::deprecated_command (link) × Deprecated command benchmark ╭─[entry #1:1:1] 1 │ benchmark · ────┬──── · ╰── 'benchmark' is deprecated. Please use 'timeit' instead. ╰──── ``` # User-Facing Changes # Tests + Formatting Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` 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.

…stStream` (#12412)  # Description  Prior, it seemed that nested errors would not get detected and shown. This PR fixes that. Resolves #10176: ``` ~/CodingProjects/nushell> [[1,2]] | each {|x| $x | each {|y| error make {msg: "oh noes"} } } 05/04/2024 21:34:08 Error: nu::shell::eval_block_with_input × Eval block failed with pipeline input ╭─[entry #1:1:3] 1 │ [[1,2]] | each {|x| $x | each {|y| error make {msg: "oh noes"} } } · ┬ · ╰── source value ╰──── Error: × oh noes ╭─[entry #1:1:36] 1 │ [[1,2]] | each {|x| $x | each {|y| error make {msg: "oh noes"} } } · ─────┬──── · ╰── originates from here ╰──── ``` Resolves #11224: ``` ~/CodingProjects/nushell> [0] | each { |_| 05/04/2024 21:35:40 ::: [0] | each { |_| ::: non-existent-command ::: } ::: } Error: nu::shell::eval_block_with_input × Eval block failed with pipeline input ╭─[entry #1:2:6] 1 │ [0] | each { |_| 2 │ [0] | each { |_| · ┬ · ╰── source value 3 │ non-existent-command ╰──── Error: nu:🐚:external_command × External command failed ╭─[entry #1:3:9] 2 │ [0] | each { |_| 3 │ non-existent-command · ──────────┬───────── · ╰── executable was not found 4 │ } ╰──── help: No such file or directory (os error 2) ``` # User-Facing Changes  # Tests + Formatting  # After Submitting

@YizhePKU

# Description Fix a regression introduced by #12921, where tilde expansion was no longer done on the external command name, breaking things like ```nushell > ~/.cargo/bin/exa ``` This properly handles quoted strings, so they don't expand: ```nushell > ^"~/.cargo/bin/exa" Error: nu::shell::external_command × External command failed ╭─[entry #1:1:2] 1 │ ^"~/.cargo/bin/exa" · ─────────┬──────── · ╰── Command `~/.cargo/bin/exa` not found ╰──── help: `~/.cargo/bin/exa` is neither a Nushell built-in or a known external command ``` This required a change to the parser, so the command name is also parsed in the same way the arguments are - i.e. the quotes on the outside remain in the expression. Hopefully that doesn't break anything else. 🤞 Fixes #13000. Should include in patch release 0.94.1 cc @YizhePKU # User-Facing Changes - Tilde expansion now works again for external commands - The `command` of `run-external` will now have its quotes removed like the other arguments if it is a literal string - The parser is changed to include quotes in the command expression of `ExternalCall` if they were present # Tests + Formatting I would like to add a regression test for this, but it's complicated because we need a well-known binary within the home directory, which just isn't a thing. We could drop one there, but that's kind of a bad behavior for a test to do. I also considered changing the home directory for the test, but that's so platform-specific - potentially could get it working on specific platforms though. Changing `HOME` env on Linux definitely works as far as tilde expansion works. - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib`

…13131) # Description Closes: #13010 It adds an additional check inside `parse_string`, and returns `unbalanced quote` if input string is unbalanced # User-Facing Changes After this pr, the following is no longer allowed: ```nushell ❯ "asdfasdf"asdfasdf Error: nu::parser::extra_token_after_closing_delimiter × Invaild characters after closing delimiter ╭─[entry #1:1:11] 1 │ "asdfasdf"asdfasdf · ────┬─── · ╰── invalid characters ╰──── help: Try removing them. ❯ 'asdfasd'adsfadf Error: nu::parser::extra_token_after_closing_delimiter × Invaild characters after closing delimiter ╭─[entry #2:1:10] 1 │ 'asdfasd'adsfadf · ───┬─── · ╰── invalid characters ╰──── help: Try removing them. ``` # Tests + Formatting Added 1 test

# Description Fixes #13280. After apply this patch, we can use non-timezone string + format option `into datetime` cmd # User-Facing Changes AS-IS (before fixing) ``` $ "09.02.2024 11:06:11" | into datetime --format '%m.%d.%Y %T' Error: nu::shell::cant_convert × Can't convert to could not parse as datetime using format '%m.%d.%Y %T'. ╭─[entry #1:1:25] 1 │ "09.02.2024 11:06:11" | into datetime --format '%m.%d.%Y %T' · ──────┬────── · ╰── can't convert input is not enough for unique date and time to could not parse as datetime using format '%m.%d.%Y %T' ╰──── help: you can use `into datetime` without a format string to enable flexible parsing $ "09.02.2024 11:06:11" | into datetime Mon, 2 Sep 2024 11:06:11 +0900 (in 2 months) ``` TO-BE(After fixing) ``` $ "09.02.2024 11:06:11" | into datetime --format '%m.%d.%Y %T' Mon, 2 Sep 2024 20:06:11 +0900 (in 2 months) $ "09.02.2024 11:06:11" | into datetime Mon, 2 Sep 2024 11:06:11 +0900 (in 2 months) ``` # Tests + Formatting If there is agreement on the direction, I will add a test. # After Submitting --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>

@amtoine

# Description From the feedbacks from @amtoine , it's good to make nushell shows error for `o>|` syntax. # User-Facing Changes ## Before ```nushell 'foo' o>| print 07/09/2024 06:44:23 AM Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #6:1:9] 1 │ 'foo' o>| print · ┬ · ╰── expected redirection target ``` ## After ```nushell 'foo' o>| print 07/09/2024 06:47:26 AM Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #1:1:7] 1 │ 'foo' o>| print · ─┬─ · ╰── expected `|`. Redirection stdout to pipe is the same as piping directly. ╰──── ``` # Tests + Formatting Added one test --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>

# Description As part of fixing #13586, this PR checks the types of the operands when creating a range. Stuff like `0..(glob .)` will be rejected at parse time. Additionally, `0..$x` will be treated as a range and rejected if `x` is not defined, rather than being treated as a string. A separate PR will need to be made to do reject streams at runtime, so that stuff like `0..(open /dev/random)` doesn't hang. Internally, this PR adds a `ParseError::UnsupportedOperationTernary` variant, for when you have a range like `1..2..(glob .)`. # User-Facing Changes Users will now receive an error if any of the operands in the ranges they construct have types that aren't compatible with `Type::Number`. Additionally, if a piece of code looks like a range but some parse error is encountered while parsing it, that piece of code will still be treated as a range and the user will be shown the parse error. This means that a piece of code like `0..$x` will be treated as a range no matter what. Previously, if `x` weren't the expression would've been treated as a string `"0..$x"`. I feel like it makes the language less complicated if we make it less context-sensitive. Here's an example of the error you get: ``` > 0..(glob .) Error: nu::parser::unsupported_operation × range is not supported between int and any. ╭─[entry #1:1:1] 1 │ 0..(glob .) · ─────┬─────┬┬ · │ │╰── any · │ ╰── int · ╰── doesn't support these values ╰──── ``` And as an image: ![image](https://github.com/user-attachments/assets/5c76168d-27db-481b-b541-861dac899dbf) Note: I made the operands themselves (above, `(glob .)`) be garbage, rather than the `..` operator itself. This doesn't match the behavior of the math operators (if you do `1 + "foo"`, `+` gets highlighted red). This is because with ranges, the range operators aren't `Expression`s themselves, so they can't be turned into garbage. I felt like here, it makes more sense to highlight the individual operand anyway.

# Description As part of fixing nushell#13586, this PR checks the types of the operands when creating a range. Stuff like `0..(glob .)` will be rejected at parse time. Additionally, `0..$x` will be treated as a range and rejected if `x` is not defined, rather than being treated as a string. A separate PR will need to be made to do reject streams at runtime, so that stuff like `0..(open /dev/random)` doesn't hang. Internally, this PR adds a `ParseError::UnsupportedOperationTernary` variant, for when you have a range like `1..2..(glob .)`. # User-Facing Changes Users will now receive an error if any of the operands in the ranges they construct have types that aren't compatible with `Type::Number`. Additionally, if a piece of code looks like a range but some parse error is encountered while parsing it, that piece of code will still be treated as a range and the user will be shown the parse error. This means that a piece of code like `0..$x` will be treated as a range no matter what. Previously, if `x` weren't the expression would've been treated as a string `"0..$x"`. I feel like it makes the language less complicated if we make it less context-sensitive. Here's an example of the error you get: ``` > 0..(glob .) Error: nu::parser::unsupported_operation × range is not supported between int and any. ╭─[entry nushell#1:1:1] 1 │ 0..(glob .) · ─────┬─────┬┬ · │ │╰── any · │ ╰── int · ╰── doesn't support these values ╰──── ``` And as an image: ![image](https://github.com/user-attachments/assets/5c76168d-27db-481b-b541-861dac899dbf) Note: I made the operands themselves (above, `(glob .)`) be garbage, rather than the `..` operator itself. This doesn't match the behavior of the math operators (if you do `1 + "foo"`, `+` gets highlighted red). This is because with ranges, the range operators aren't `Expression`s themselves, so they can't be turned into garbage. I felt like here, it makes more sense to highlight the individual operand anyway.

# Description This PR makes it so that non-zero exit codes and termination by signal are treated as a normal `ShellError`. Currently, these are silent errors. That is, if an external command fails, then it's code block is aborted, but the parent block can sometimes continue execution. E.g., see #8569 and this example: ```nushell [1 2] | each { ^false } ``` Before this would give: ``` ╭───┬──╮ │ 0 │ │ │ 1 │ │ ╰───┴──╯ ``` Now, this shows an error: ``` Error: nu::shell::eval_block_with_input × Eval block failed with pipeline input ╭─[entry #1:1:2] 1 │ [1 2] | each { ^false } · ┬ · ╰── source value ╰──── Error: nu:🐚:non_zero_exit_code × External command had a non-zero exit code ╭─[entry #1:1:17] 1 │ [1 2] | each { ^false } · ──┬── · ╰── exited with code 1 ╰──── ``` This PR fixes #12874, fixes #5960, fixes #10856, and fixes #5347. This PR also partially addresses #10633 and #10624 (only the last command of a pipeline is currently checked). It looks like #8569 is already fixed, but this PR will make sure it is definitely fixed (fixes #8569). # User-Facing Changes - Non-zero exit codes and termination by signal now cause an error to be thrown. - The error record value passed to a `catch` block may now have an `exit_code` column containing the integer exit code if the error was due to an external command. - Adds new config values, `display_errors.exit_code` and `display_errors.termination_signal`, which determine whether an error message should be printed in the respective error cases. For non-interactive sessions, these are set to `true`, and for interactive sessions `display_errors.exit_code` is false (via the default config). # Tests Added a few tests. # After Submitting - Update docs and book. - Future work: - Error if other external commands besides the last in a pipeline exit with a non-zero exit code. Then, deprecate `do -c` since this will be the default behavior everywhere. - Add a better mechanism for exit codes and deprecate `$env.LAST_EXIT_CODE` (it's buggy).

# Description Old code was comparing remaining positional arguments with total number of arguments, where it should've compared remaining positional with with remaining arguments of any kind. This means that if a function was given too few arguments, `calculate_end_span` would believe that it actually had too many arguments, since after parsing the first few arguments, the number of remaining arguments needed were fewer than the *total* number of arguments, of which we had used several. Fixes #9072 Fixes: #13930 Fixes: #12069 Fixes: #8385 Extracted from #10381 ## Bonus It also improves the error handling on missing positional arguments before keywords (no longer crashing since #9851). Instead of just giving the keyword to the parser for the missing positional, we give an explicit error about a missing positional argument. I would like better descriptions than "missing var_name" though, but I'm not sure if that's available without Old error ``` Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #1:1:1] 1 │ let = if foo · ┬ · ╰── expected valid variable name ╰──── ``` New error ``` Error: nu::parser::missing_positional × Missing required positional argument. ╭─[entry #18:1:1] 1 │ let = foo · ┬ · ╰── missing var_name ╰──── help: Usage: let <var_name> = <initial_value> ``` # User-Facing Changes The program `alias = = =` is no longer accepted by the parser

# Description This PR updates `group-by` and `split-by` to allow other nushell Values to be used, namely bools. ### Before ```nushell ❯ [false, false, true, false, true, false] | group-by | table -e Error: nu::shell::cant_convert × Can't convert to string. ╭─[entry #1:1:2] 1 │ [false, false, true, false, true, false] | group-by | table -e · ──┬── · ╰── can't convert bool to string ╰──── ``` ### After ```nushell ❯ [false, false, true, false, true, false] | group-by | table -e ╭───────┬───────────────╮ │ │ ╭───┬───────╮ │ │ false │ │ 0 │ false │ │ │ │ │ 1 │ false │ │ │ │ │ 2 │ false │ │ │ │ │ 3 │ false │ │ │ │ ╰───┴───────╯ │ │ │ ╭───┬──────╮ │ │ true │ │ 0 │ true │ │ │ │ │ 1 │ true │ │ │ │ ╰───┴──────╯ │ ╰───────┴───────────────╯ ``` # User-Facing Changes  # Tests + Formatting  # After Submitting

Fixes #14023 # Description - Prevents "failed to find added variable" when modules export constants with type signatures: ```nushell > module foo { export const bar: int = 2 } Error: nu::parser::unknown_state × Internal error. ╭─[entry #1:1:21] 1 │ module foo { export const bar: int = 2 } · ─────────┬──────── · ╰── failed to find added variable ``` - Returns `name_is_builtin_var` errors for names with type signatures: ```nushell > let env: string = ""; Error: nu::parser::name_is_builtin_var × `env` used as variable name. ╭─[entry #1:1:5] 1 │ let env: string = ""; · ─┬─ · ╰── already a builtin variable ```

# Description  This PR fixes the quoting and escaping of column names in `to nuon`. Before the PR, column names with quotes inside them would get quoted, but not escaped: ```nushell > { 'a"b': 2 } | to nuon { "a"b": 2 } > { 'a"b': 2 } | to nuon | from nuon Error: × error when loading nuon text ╭─[entry #1:1:27] 1 │ { "a\"b": 2 } | to nuon | from nuon · ────┬──── · ╰── could not load nuon text ╰──── Error: × error when parsing nuon text ╭─[entry #1:1:27] 1 │ { "a\"b": 2 } | to nuon | from nuon · ────┬──── · ╰── could not parse nuon text ╰──── Error: × error when parsing ╭──── 1 │ {"a"b": 2} · ┬ · ╰── Unexpected end of code. ╰──── > [['a"b']; [2] [3]] | to nuon [["a"b"]; [2], [3]] > [['a"b']; [2] [3]] | to nuon | from nuon Error: × error when loading nuon text ╭─[entry #1:1:32] 1 │ [['a"b']; [2] [3]] | to nuon | from nuon · ────┬──── · ╰── could not load nuon text ╰──── Error: × error when parsing nuon text ╭─[entry #1:1:32] 1 │ [['a"b']; [2] [3]] | to nuon | from nuon · ────┬──── · ╰── could not parse nuon text ╰──── Error: × error when parsing ╭──── 1 │ [["a"b"]; [2], [3]] · ┬ · ╰── Unexpected end of code. ╰──── ``` After this PR, the quote is escaped properly: ```nushell > { 'a"b': 2 } | to nuon { "a\"b": 2 } > { 'a"b': 2 } | to nuon | from nuon ╭─────┬───╮ │ a"b │ 2 │ ╰─────┴───╯ > [['a"b']; [2] [3]] | to nuon [["a\"b"]; [2], [3]] > [['a"b']; [2] [3]] | to nuon | from nuon ╭─────╮ │ a"b │ ├─────┤ │ 2 │ │ 3 │ ╰─────╯ ``` The cause of the issue was that `to nuon` simply wrapped column names in `'"'` instead of calling `escape_quote_string`. As part of this change, I also moved the functions related to quoting (`needs_quoting` and `escape_quote_string`) into `nu-utils`, since previously they were defined in very ad-hoc places (and, in the case of `escape_quote_string`, it was defined multiple times with the same body!). # User-Facing Changes  `to nuon` now properly escapes quotes in column names. # Tests + Formatting  All tests pass, including workspace and stdlib tests. # After Submitting

# User-Facing Changes `def` now errors instead of silently ignoring closure blocks: ```nushell > def foo [] {|bar| } Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry nushell#1:1:12] 1 │ def foo [] {|bar| } · ────┬─── · ╰── expected definition body { ... } ╰──── ```

# User-Facing Changes - Special characters in module names are replaced with underscores when importing constants, preventing "expected valid variable name": ```nushell > module foo-bar { export const baz = 1 } > use foo-bar > $foo_bar.baz ``` - "expected valid variable name" errors now include a suggestion list: ```nushell > module foo-bar { export const baz = 1 } > use foo-bar > $foo-bar Error: nu::parser::parse_mismatch_with_did_you_mean × Parse mismatch during operation. ╭─[entry nushell#1:1:1] 1 │ $foo-bar; · ────┬─── · ╰── expected valid variable name. Did you mean '$foo_bar'? ╰──── ```

# User-Facing Changes `def` now errors instead of silently ignoring closure blocks: ```nushell > def foo [] {|bar| } Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry nushell#1:1:12] 1 │ def foo [] {|bar| } · ────┬─── · ╰── expected definition body { ... } ╰──── ```

# User-Facing Changes - Special characters in module names are replaced with underscores when importing constants, preventing "expected valid variable name": ```nushell > module foo-bar { export const baz = 1 } > use foo-bar > $foo_bar.baz ``` - "expected valid variable name" errors now include a suggestion list: ```nushell > module foo-bar { export const baz = 1 } > use foo-bar > $foo-bar Error: nu::parser::parse_mismatch_with_did_you_mean × Parse mismatch during operation. ╭─[entry nushell#1:1:1] 1 │ $foo-bar; · ────┬─── · ╰── expected valid variable name. Did you mean '$foo_bar'? ╰──── ```

Add support for skip and where

cbb86b0

wycats merged commit 3c5117f into nushell:master May 16, 2019

robg204 mentioned this pull request Aug 24, 2019

opening a source file for viewing with the internal pager seems to core #388

Closed

sophiajt pushed a commit that referenced this pull request Sep 28, 2019

Newbra (#1)

74e60fb

Newbra

avimar mentioned this pull request Oct 18, 2019

SSL error on 0.3.0 Release: on Debian GNU/Linux 9.9 (stretch) #765

Closed

sophiajt pushed a commit that referenced this pull request Nov 11, 2019

fix(ci): can't push to quay.io (#1)

3e14de1

* ci(github): lowercase ${{ github.actor }} * ci(github): fix robot username * fix(ci): fix tag name on suffixed version

thegedge mentioned this pull request Aug 26, 2020

Configurable behavior on expression (not command) input | Unnamed alias #2411

Closed

stormasm mentioned this pull request Jan 27, 2021

scripts broken when left parentheses not on same line as def #2972

Closed

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

Merge pull request nushell#1 from nschoellhorn/main

794a004

Implement primitive word-jumping

fdncred mentioned this pull request Jul 30, 2021

document engine-p porting #3868

Merged

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

Merge pull request nushell#1 from jonathandturner/checkpiont

049477a

Removed file_id in Span, compact file sources

henryrt mentioned this pull request Feb 9, 2022

Fix "Index out of bounds" when input to the group-by filter is empty. #4369 #4382

Merged

3 tasks

lafirest mentioned this pull request Jun 23, 2022

git fetch origin foo will failed #5858

Closed

rgwood mentioned this pull request Aug 29, 2022

Remove ASSOC and FTYPE from allowed CMD builtins #6441

Closed

3 tasks

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

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

3c9ae2e

a first design test

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

Merge pull request nushell#1 from pontaoski/main

f4957ea

Initial draft of website

NotTheDr01ds mentioned this pull request Apr 19, 2024

(Assumed) Race-condition leads to par-each/rm error #12585

Open

Schweber mentioned this pull request May 21, 2024

Let into filesize handle decimal strings #12926

Closed

NotTheDr01ds mentioned this pull request May 23, 2024

Spans returned by ast are incorrect #12945

Open

Araxeus mentioned this pull request Jun 3, 2024

nu::shell::io_error when trying to run file on windows #13020

Closed

twilwa mentioned this pull request Sep 27, 2024

config.nu does not persist defined custom commands. #13942

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for skip and where #1

Add support for skip and where #1

sophiajt commented May 16, 2019

Add support for skip and where #1

Add support for skip and where #1

Conversation

sophiajt commented May 16, 2019