Workaround color prompt by making our own helper #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wycats
approved these changes
May 16, 2019
sophiajt
pushed a commit
that referenced
this pull request
Jul 5, 2020
* Add args in .nurc file to environment * Working dummy version * Add add_nurc to sync_env command * Parse .nurc file * Delete env vars after leaving directory * Removing vals not working, strangely * Refactoring, add comment * Debugging * Debug by logging to file * Add and remove env var behavior appears correct However, it does not use existing code that well. * Move work to cli.rs * Parse config directories * I am in a state of distress * Rename .nurc to .nu * Some notes for me * Refactoring * Removing vars works, but not done in a very nice fashion * Refactor env_vars_to_delete * Refactor env_vars_to_add() * Move directory environment code to separate file * Refactor from_config * Restore env values * Working? * Working? * Update comments and change var name * Formatting * Remove vars after leaving dir * Remove notes I made * Rename config function * Clippy * Cleanup and handle errors * cargo fmt * Better error messages, remove last (?) unwrap * FORMAT PLZ * Rename whitelisted_directories to allowed_directories * Add comment to clarify how overwritten values are restored. * Change list of allowed dirs to indexmap * Rewrite starting * rewrite everything * Overwritten env values tracks an indexmap instead of vector * Refactor restore function * Untrack removed vars properly * Performance concerns * Performance concerns * Error handling * Clippy * Add type aliases for String and OsString * Deletion almost works * Working? * Error handling and refactoring * nicer errors * Add TODO file * Move outside of loop * Error handling * Reworking adding of vars * Reworking adding of vars * Ready for testing * Refactoring * Restore overwritten vals code * todo.org * Remove overwritten values tracking, as it is not needed * Cleanup, stop tracking overwritten values as nu takes care of it * Init autoenv command * Initialize autoenv and autoenv trust * autoenv trust toml * toml * Use serde for autoenv * Optional directory arg * Add autoenv untrust command * ... actually add autoenv untrust this time * OsString and paths * Revert "OsString and paths" This reverts commit e6eedf8. * Fix path * Fix path * Autoenv trust and untrust * Start using autoenv * Check hashes * Use trust functionality when setting vars * Remove unused code * Clippy * Nicer errors for autoenv commands * Non-working errors * Update error description * Satisfy fmt * Errors * Errors print, but not nicely * Nicer errors * fmt * Delete accidentally added todo.org file * Rename direnv to autoenv * Use ShellError instead of Error * Change tests to pass, danger zone? * Clippy and errors * Clippy... again * Replace match with or_else * Use sha2 crate for hashing * parsing and error msg * Refactoring * Only apply vars once * if parent dir * Delete vars * Rework exit code * Adding works * restore * Fix possibility of infinite loop * Refactoring * Non-working * Revert "Non-working" This reverts commit e231b85. * Revert "Revert "Non-working"" This reverts commit 804092e. * Autoenv trust works without restart * Cargo fix * Script vars * Serde * Serde errors * Entry and exitscripts * Clippy * Support windows and handle errors * Formatting * Fix infinite loop on windows * Debugging windows loop * More windows infinite loop debugging * Windows loop debugging #3 * windows loop #4 * Don't return err * Cleanup unused code * Infinite loop debug * Loop debugging * Check if infinite loop is vars_to_add * env_vars_to_add does not terminate, skip loop as test * Hypothesis: std::env::current_dir() is messing with something * Hypothesis: std::env::current_dir() is messing with something * plz * make clippy happy * debugging in env_vars_to_add * Debbuging env_vars_to_add #2 * clippy * clippy.. * Fool clippy * Fix another infinite loop * Binary search for error location x) * Binary search #3 * fmt * Binary search #4 * more searching... * closing in... maybe * PLZ * Cleanup * Restore commented out functionality * Handle case when user gives the directory "." * fmt * Use fs::canonicalize for paths * Create optional script section * fmt * Add exitscripts even if no entryscripts are defined * All sections in .nu-env are now optional * Re-read config file each directory change * Hot reload after autoenv untrust, don't run exitscripts if untrusted * Debugging * Fix issue with recursive adding of vars * Thank you for finding my issues Mr. Azure * use std::env
sophiajt
pushed a commit
that referenced
this pull request
Apr 20, 2021
* Add new path parse subcommand
This includes a slight refactor to all the path subcommand `action()`
functions.
* Remove filestem and extension; Fix example
* Add additional description to path parse
* Put join arg behind flag; Fix missing import (Win)
* Fix error when column path is passed as arg
* Add structured path joining
Structured path is implicitly joined at every patch subcommand call.
* Fix existing path join tests; Fix rustfmt
* Remove redundant 'static lifetime (clippy)
* Add initial impl of path split subcommand
* Add ability to join path from parts
* Fix wrong results in path split examples
* Fix remaining asyncs after engine change
* Do not wrap split path parts into table
When the input is just a list of values, the `path split` command will
split each value directly into the output stream, similar to
`split-row`. Column path--specified values are still wrapped into a
table so they can still be used to replace table fields.
* Join list of values instead of going one-by-one
When `path join` encounters a list of values, it attempts to join them,
instead of going one-by-one like the rest of the path commands. You can
still `each { echo $it | path join }` to join them one-by-one, if the
values are, e.g., tables.
Now, the behavior of `path split` and `path join` should match the
`split-row` and `str collect` counterparts and should hopefully align
better with user's expectations.
* Make sure path join detects structured path
* Fix panic on empty input stream
Also, doesn't collect input into vector unnecessarily.
* Fix path join not appending value
* Remove argument serialization
* Make better errors; Misc refactor
* OsStr -> String encoding is now lossy, instead of throwing an error
* The consequence is action() now always returns Value instead of Result
* Removed redundant handle_value() call in `path join`
* Fix possible incorrect error detection in `path split`
* Applied rustfmt + clippy
* Add more usage, examples & test; Fix type error
The 'parent' column was required to be a path but didn't work with
string.
* Add more help & examples; Maybe fix Windows error
* Refactor operate function
Reducing code repetition
* Review usages and examples
* Add the option to manually specify the extension
* Add more tests; Fix failures on Windows
* Move path commands to engine-p
* Small refactor
fdncred
added a commit
that referenced
this pull request
Jul 9, 2021
* kind of works but not what we really want * updated `into binary` and `first` to work better together * attempt to fix wasm build problem * attempt #2 to fix wasm stuff
elferherrera
pushed a commit
to elferherrera/nushell
that referenced
this pull request
Feb 7, 2022
Revert "Removed file_id in Span, compact file sources"
elferherrera
pushed a commit
to elferherrera/nushell
that referenced
this pull request
Feb 7, 2022
elferherrera
pushed a commit
to elferherrera/nushell
that referenced
this pull request
Feb 7, 2022
Try nushell#2 - Mac/Windows CI
kubouch
pushed a commit
that referenced
this pull request
Feb 7, 2022
6 tasks
sophiajt
pushed a commit
that referenced
this pull request
Nov 23, 2022
# 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.
kubouch
pushed a commit
that referenced
this pull request
Dec 10, 2022
# 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.
rgwood
pushed a commit
that referenced
this pull request
Dec 23, 2022
…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.
rgwood
added a commit
that referenced
this pull request
Jan 1, 2023
A tiny follow-up from #7623, changes "Only supports for specific input types" to "Input type not supported" Before: ``` 〉"asdf" | append "foo" Error: nu::shell::only_supports_this_input_type (link) × Only supports for specific input types. ╭─[entry #2:1:1] 1 │ "asdf" | append "foo" · ───┬── ───┬── · │ ╰── only list, binary, raw data or range input data is supported · ╰── input type: string ╰──── ``` After: ``` 〉"asdf" | append "foo" Error: nu:🐚:only_supports_this_input_type (link) × Input type not supported. ╭─[entry #2:1:1] 1 │ "asdf" | append "foo" · ───┬── ───┬── · │ ╰── only list, binary, raw data or range input data is supported · ╰── input type: string ╰──── ```
Hofer-Julian
pushed a commit
to Hofer-Julian/nushell
that referenced
this pull request
Jan 27, 2023
add CONTRIBUTING, without and with Docker
fdncred
added a commit
that referenced
this pull request
Feb 9, 2023
# 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.
rgwood
added a commit
that referenced
this pull request
Feb 13, 2023
# Description [GH issue](#8027) The current error message for a cd command includes a Debug output of the `io::Error` being returned from `canonicalize_with`, so it's been replaced with a more user friendly and readable depiction of the error. # User-Facing Changes As described in the issue, I've changed the error message for a cd into a directory that does not exist from: ``` /home/rdevenney/projects/open_source/nushell〉cd asdfasdf 02/11/2023 08:59:59 PM Error: nu::shell::directory_not_found (link) × Directory not found ╭─[entry #2:1:1] 1 │ cd asdfasdf · ────┬─── · ╰── directory not found ╰──── help: IO Error: Os { code: 2, kind: NotFound, message: "No such file or directory" } ``` To: ``` /home/rdevenney/projects/open_source/nushell〉cd asdfasdf 02/11/2023 08:58:38 PM Error: nu:🐚:directory_not_found (link) × Directory not found ╭─[entry #1:1:1] 1 │ cd asdfasdf · ────┬─── · ╰── directory not found ╰──── help: IO Error: DirectoryNotFound ``` # 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. --------- Co-authored-by: Reilly Wood <reilly.wood@icloud.com>
sholderbach
added a commit
that referenced
this pull request
Feb 13, 2023
# Description Added a few syntax errors in ints and strings, changed parser to stop and show that error rather than continue trying to parse those tokens as some other shape. However, I don't see how to push this direction much further, and most of the classic confusing errors can't be changed. Flagged as WIP for the moment, but passes all checks and works better than current release: 1. I have yet to figure out how to make these errors refer back to the book, as I see some other errors do. 2. How to give syntax error when malformed int is first token in line? Currently parsed as external command, user gets confusing error message. 3. Would like to be more strict with *decimal* int literals (lacking, e.g, `0x' prefix). Need to tinker more with the order of parse shape calls, currently, float is tried after int, so '1.4' has to be passed. _(Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience.)_ ```bash 〉"\z" Error: ╭─[entry #3:1:1] 1 │ "\z" · ─┬─ · ╰── Syntax error in string, unrecognized character after escape '\'. ╰──── ``` Canonic presentation of a syntax error. ```bash 〉" \u{01ffbogus}" Error: × Invalid syntax ╭─[entry #2:1:1] 1 │ " \u{01ffbogus}" · ───────┬────── · ╰── Syntax error in string, expecting 1 to 6 hex digits in unicode escape '\u{X...}', max value 10FFFF. ╰──── ``` Malformed unicode escape in string, flagged as error. String parse can be opinionated, it's the last shape tried. ```bash 〉0x22bogus Error: nu:🐚:external_command (link) × External command failed ╭─[entry #4:1:1] 1 │ 0x22bogus · ────┬──── · ╰── executable was not found ╰──── help: No such file or directory (os error 2) ``` A *correct* number in first token would be evaluated, but an *incorrect* one is treated as external command? Confusing to users. ```bash 〉0 + 0x22bogus Error: × Invalid syntax ╭─[entry #5:1:1] 1 │ 0 + 0x22bogus · ────┬──── · ╰── Syntax error in int, invalid digits in radix 16 int. ╰──── ``` Can give syntax error if token is unambiguously int literal. e.g has 0b or 0x prefix, could not be a float. ```bash 〉0 + 098bogus Error: nu::parser::unsupported_operation (link) × Types mismatched for operation. ╭─[entry #6:1:1] 1 │ 0 + 098bogus · ┬ ┬ ────┬─── · │ │ ╰── string · │ ╰── doesn't support these values. · ╰── int ╰──── help: Change int or string to be the right types and try again. ``` But *decimal* literal (no prefix) can't be too strict. Parser is going to try float later. So '1.4' must be passed. # User-Facing Changes First and foremost, more specific error messages for typos in string and int literals. Probably improves interactive user experience. But a script that was causing and then checking for specific error might notice a different error message. _(List of all changes that impact the user experience here. This helps us keep track of breaking changes.)_ # Tests + Formatting Added (positive and negative unit tests in `cargo test -p nu-parser`. Didn't add integration tests. Make sure you've run and fixed any issues with these commands: - [x] `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` to check that you're using the standard code style - [x] `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. --------- Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
fdncred
added a commit
that referenced
this pull request
Feb 22, 2023
# Description closes #8153 This PR allows different types of lists, like `list<string>` and `list<any>` to be appended with the `++=` operator. ## Before ``` mut args = [ hello ("hello" | path join world)] $args ++= [ foo bar ] Error: nu::parser::type_mismatch (link) × Type mismatch during operation. ╭─[entry #2:1:1] 1 │ $args ++= [ foo bar ] · ─────┬───── · ╰── expected list<any>, found list<string> ╰──── ``` ## After ``` mut args = [ hello ("hello" | path join world)] $args ++= [ foo bar ] $args ╭───┬─────────────╮ │ 0 │ hello │ │ 1 │ hello\world │ │ 2 │ foo │ │ 3 │ bar │ ╰───┴─────────────╯ ``` # 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.
rgwood
pushed a commit
that referenced
this pull request
Mar 1, 2023
# Description This change fixes the bug associated with an incorrect span in `type_mismatch` error message as described in #7288 The `span` argument in the method `into_value` was not being used to convert a `PipelineData::Value` type so when called in [eval_expression](https://github.com/nushell/nushell/blob/main/crates/nu-engine/src/eval.rs#L514-L515), the original expression's span was not being used to overwrite the result of `eval_subexpression`. # User-Facing Changes Using the example described in the issue, the whole bracketed subexpression is correctly underlined. Behavior before change: ``` let val = 10 ($val | into string) + $val Error: nu::shell::type_mismatch × Type mismatch during operation. ╭─[entry #2:1:1] 1 │ ($val | into string) + $val · ─────┬───── ┬ ──┬─ · │ │ ╰── int · │ ╰── type mismatch for operator · ╰── string ╰──── ``` Behavior after change: ``` let val = 10 ($val | into string) + $val Error: nu:🐚:type_mismatch × Type mismatch during operation. ╭─[entry #2:1:1] 1 │ ($val | into string) + $val · ──────────┬───────── ┬ ──┬─ · │ │ ╰── int · │ ╰── type mismatch for operator · ╰── string ╰──── ``` # 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.
rgwood
pushed a commit
that referenced
this pull request
Mar 16, 2023
# Description Fixes: #8402 #8391 The cause of these issue if when we want to evaluate a expression with `Value::Error`, nushell show error immediately. To fix the issue, we can wrap the `Value::Error` into a `Value::Record`. So user can see the message he want. # User-Facing Changes Before ``` ❯ try { 1 / 0 } catch {|e| echo $"error is ($e)"} Error: nu::shell::division_by_zero × Division by zero. ╭─[entry #2:1:1] 1 │ try { 1 / 0 } catch {|e| echo $"error is ($e)"} · ┬ · ╰── division by zero ╰──── ``` After ``` ❯ try { 1 / 0 } catch {|e| echo $"error is ($e)"} error is {msg: Division by zero., debug: DivisionByZero { span: Span { start: 43104, end: 43105 } }, raw: DivisionByZero { sp an: Span { start: 43104, end: 43105 } }} ``` As we can see, error becomes a record with `msg`, `debug`, `raw` columns. 1. msg column is a user friendly message. 2. debug column is more about `Value::Error` information as a string. 3. raw column is a `Value::Error` itself, if user want to re-raise the error, just use `$e | get raw` # 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 > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` # After Submitting If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date.
fdncred
pushed a commit
that referenced
this pull request
Mar 17, 2023
# Description As title, closes: #7921 closes: #8273 # User-Facing Changes when define a closure without pipe, nushell will raise error for now: ``` ❯ let x = {ss ss} Error: nu::parser::closure_missing_pipe × Missing || inside closure ╭─[entry #2:1:1] 1 │ let x = {ss ss} · ───┬─── · ╰── Parsing as a closure, but || is missing ╰──── help: Try add || to the beginning of closure ``` `any`, `each`, `all`, `where` command accepts closure, it forces user input closure like `{||`, or parse error will returned. ``` ❯ {major:2, minor:1, patch:4} | values | each { into string } Error: nu::parser::closure_missing_pipe × Missing || inside closure ╭─[entry #4:1:1] 1 │ {major:2, minor:1, patch:4} | values | each { into string } · ───────┬─────── · ╰── Parsing as a closure, but || is missing ╰──── help: Try add || to the beginning of closure ``` `with-env`, `do`, `def`, `try` are special, they still remain the same, although it says that it accepts a closure, but they don't need to be written like `{||`, it's more likely a block but can capture variable outside of scope: ``` ❯ def test [input] { echo [0 1 2] | do { do { echo $input } } }; test aaa aaa ``` Just realize that It's a big breaking change, we need to update config and scripts... # 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.
rgwood
added a commit
that referenced
this pull request
Mar 23, 2023
Closes #8546. ### Before: ``` > mv foo.txt bar.txt Error: × Invalid file or pattern ╭─[entry #2:1:1] 1 │ mv foo.txt bar.txt · ───┬─── · ╰── invalid file or pattern ╰──── ``` ### After: ``` > mv foo.txt bar.txt Error: × File(s) not found ╭─[entry #2:1:1] 1 │ mv foo.txt bar.txt · ───┬─── · ╰── could not find any files matching this glob pattern ╰──── ```
gaetschwartz
pushed a commit
to gaetschwartz/nushell
that referenced
this pull request
Oct 20, 2023
follow-up to - nushell#10566 # Description this PR deprecates the use of `extern-wrapped` and `export extern-wrapped` these two core commands will be removed in 0.88 # User-Facing Changes using `extern-wrapped` will give a warning ```nushell > extern-wrapped foo [...args] { print "foo" }; foo Error: × Deprecated command ╭─[entry nushell#2:1:1] 1 │ extern-wrapped foo [...args] { print "foo" }; foo · ───────┬────── · ╰── `extern-wrapped` is deprecated and will be removed in 0.88. ╰──── help: Use `def --wrapped` instead foo ``` # Tests + Formatting # After Submitting
sholderbach
added a commit
that referenced
this pull request
Nov 1, 2023
# Description Pretty much all operations/commands in Nushell assume that the column names/keys in a record and thus also in a table (which consists of a list of records) are unique. Access through a string-like cell path should refer to a single column or key/value pair and our output through `table` will only show the last mention of a repeated column name. ```nu [[a a]; [1 2]] ╭─#─┬─a─╮ │ 0 │ 2 │ ╰───┴───╯ ``` While the record parsing already either errors with the `ShellError::ColumnDefinedTwice` or silently overwrites the first occurence with the second occurence, the table literal syntax `[[header columns]; [val1 val2]]` currently still allowed the creation of tables (and internally records with more than one entry with the same name. This is not only confusing, but also breaks some assumptions around how we can efficiently perform operations or in the past lead to outright bugs (e.g. #8431 fixed by #8446). This PR proposes to make this an error. After this change another hole which allowed the construction of records with non-unique column names will be plugged. ## Parts - Fix `SE::ColumnDefinedTwice` error code - Remove previous tests permitting duplicate columns - Deny duplicate column in table literal eval - Deny duplicate column in const eval - Deny duplicate column in `from nuon` # User-Facing Changes `[[a a]; [1 2]]` will now return an error: ``` Error: nu::shell::column_defined_twice × Record field or table column used twice ╭─[entry #2:1:1] 1 │ [[a a]; [1 2]] · ┬ ┬ · │ ╰── field redefined here · ╰── field first defined here ╰──── ``` this may under rare circumstances block code from evaluating. Furthermore this makes some NUON files invalid if they previously contained tables with repeated column names. # Tests + Formatting Added tests for each of the different evaluation paths that materialize tables.
WindSoilder
added a commit
that referenced
this pull request
Nov 23, 2023
#10851) # Description Fixes: #10271 Given the following script: ```shell # test.sh echo aaaaa echo bbbbb 1>&2 echo cc ``` This pr makes the following command possible: ```nushell bash test.sh err> /dev/null | lines | each {|line| $line | str length} ``` ## General idea behind the change: When nushell redirect stderr message to external file 1. it take stdout of external stream, and pass this stream to next command, so it won't block next pipeline command from running. 2. relative stderr stream are handled by `save` command These two streams are handled separately, so we need to delegate a thread to `save` command, or else we'll have a chance to hang nushell, we have meet a similar before: #5625. ### One case to consider What if we're failed to save to an external stream? (Like we don't have a permission to save to a file)? In this case nushell will just print a waning message, and don't stop the following scripts from running. # User-Facing Changes ## Before ```nushell ❯ bash test2.sh err> /dev/null | lines | each {|line| $line | str length} aaaaa cc ``` ## After ```nushell ❯ bash test2.sh err> /dev/null | lines | each {|line| $line | str length} ╭───┬───╮ │ 0 │ 5 │ │ 1 │ 2 │ ╰───┴───╯ ``` BTY, after this pr, the following commands are impossible either, it's important to make sure that the implementation doesn't introduce too much costs: ```nushell ❯ echo a e> a.txt e> a.txt Error: × Can't make stderr redirection twice ╭─[entry #1:1:1] 1 │ echo a e> a.txt e> a.txt · ─┬ · ╰── try to remove one ╰──── ❯ echo a o> a.txt o> a.txt Error: × Can't make stdout redirection twice ╭─[entry #2:1:1] 1 │ echo a o> a.txt o> a.txt · ─┬ · ╰── try to remove one ╰──── ```
amtoine
pushed a commit
that referenced
this pull request
Nov 29, 2023
Goes towards implementing #10598, which asks for a spread operator in lists, in records, and when calling commands (continuation of #11006, which only implements it in lists) # Description This PR is for adding a spread operator that can be used when building records. Additional functionality can be added later. Changes: - Previously, the `Expr::Record` variant held `(Expression, Expression)` pairs. It now holds instances of an enum `RecordItem` (the name isn't amazing) that allows either a key-value mapping or a spread operator. - `...` will be treated as the spread operator when it appears before `$`, `{`, or `(` inside records (no whitespace allowed in between) (not implemented yet) - The error message for duplicate columns now includes the column name itself, because if two spread records are involved in such an error, you can't tell which field was duplicated from the spans alone `...` will still be treated as a normal string outside records, and even in records, it is not treated as a spread operator when not followed immediately by a `$`, `{`, or `(`. # User-Facing Changes Users will be able to use `...` when building records. ``` > let rec = { x: 1, ...{ a: 2 } } > $rec ╭───┬───╮ │ x │ 1 │ │ a │ 2 │ ╰───┴───╯ > { foo: bar, ...$rec, baz: blah } ╭─────┬──────╮ │ foo │ bar │ │ x │ 1 │ │ a │ 2 │ │ baz │ blah │ ╰─────┴──────╯ ``` If you want to update a field of a record, you'll have to use `merge` instead: ``` > { ...$rec, x: 5 } Error: nu::shell::column_defined_twice × Record field or table column used twice: x ╭─[entry #2:1:1] 1 │ { ...$rec, x: 5 } · ──┬─ ┬ · │ ╰── field redefined here · ╰── field first defined here ╰──── > $rec | merge { x: 5 } ╭───┬───╮ │ x │ 5 │ │ a │ 2 │ ╰───┴───╯ ``` # Tests + Formatting # After Submitting
sholderbach
pushed a commit
that referenced
this pull request
Dec 5, 2023
# Description Fixes: #11143 # User-Facing Changes Take the following as example: ```nushell module foo { export def bar [] {}; export def baz [] {} } ``` `use foo bar baz` will be error: ``` ❯ use foo c d Error: nu::parser::wrong_import_pattern × Wrong import pattern structure. ╭─[entry #2:1:1] 1 │ use foo c d · ┬ · ╰── Trying to import something but the parent `c` is not a module, maybe you want to try `use <module> [<name1>, <name2>]` ╰──── ``` # Tests + Formatting Done
amtoine
added a commit
that referenced
this pull request
Dec 11, 2023
this will allow to run ```nushell format date --list | get 0 ``` and get ``` ─────────────┬─────────────────────────────────────────────────────────── Specification│%Y Example │2023 Description │The full proleptic Gregorian year, zero-padded to 4 digits. ─────────────┴─────────────────────────────────────────────────────────── ``` instead of currently ``` Error: nu::parser::input_type_mismatch × Command does not support string input. ╭─[entry #2:1:1] 1 │ format date --list | get 0 · ─┬─ · ╰── command doesn't support string input ╰──── ```
hardfau1t
pushed a commit
to hardfau1t/nushell
that referenced
this pull request
Dec 14, 2023
related to - nushell#9373 - nushell#8639 might be able to close nushell#8639? # Description "can't follow stream paths" errors have always been a bit scary and obnoxious because they give no information about what happens... in this PR i try to slightly improve the error message by telling if the stream was empty or not and give span information when available. # User-Facing Changes ```nushell > update value (get value) Error: nu::shell::incompatible_path_access × Data cannot be accessed with a cell path ╭─[entry #1:1:1] 1 │ update value (get value) · ─┬─ · ╰── empty pipeline doesn't support cell paths ╰──── ``` ```nushell > ^echo "foo" | get 0 Error: nu:🐚:incompatible_path_access × Data cannot be accessed with a cell path ╭─[entry nushell#2:1:1] 1 │ ^echo "foo" | get 0 · ──┬─ · ╰── external stream doesn't support cell paths ╰──── ``` # Tests + Formatting # After Submitting
hardfau1t
pushed a commit
to hardfau1t/nushell
that referenced
this pull request
Dec 14, 2023
follow-up to - nushell#10566 # Description this PR deprecates the use of `extern-wrapped` and `export extern-wrapped` these two core commands will be removed in 0.88 # User-Facing Changes using `extern-wrapped` will give a warning ```nushell > extern-wrapped foo [...args] { print "foo" }; foo Error: × Deprecated command ╭─[entry nushell#2:1:1] 1 │ extern-wrapped foo [...args] { print "foo" }; foo · ───────┬────── · ╰── `extern-wrapped` is deprecated and will be removed in 0.88. ╰──── help: Use `def --wrapped` instead foo ``` # Tests + Formatting # After Submitting
hardfau1t
pushed a commit
to hardfau1t/nushell
that referenced
this pull request
Dec 14, 2023
# Description Pretty much all operations/commands in Nushell assume that the column names/keys in a record and thus also in a table (which consists of a list of records) are unique. Access through a string-like cell path should refer to a single column or key/value pair and our output through `table` will only show the last mention of a repeated column name. ```nu [[a a]; [1 2]] ╭─#─┬─a─╮ │ 0 │ 2 │ ╰───┴───╯ ``` While the record parsing already either errors with the `ShellError::ColumnDefinedTwice` or silently overwrites the first occurence with the second occurence, the table literal syntax `[[header columns]; [val1 val2]]` currently still allowed the creation of tables (and internally records with more than one entry with the same name. This is not only confusing, but also breaks some assumptions around how we can efficiently perform operations or in the past lead to outright bugs (e.g. nushell#8431 fixed by nushell#8446). This PR proposes to make this an error. After this change another hole which allowed the construction of records with non-unique column names will be plugged. ## Parts - Fix `SE::ColumnDefinedTwice` error code - Remove previous tests permitting duplicate columns - Deny duplicate column in table literal eval - Deny duplicate column in const eval - Deny duplicate column in `from nuon` # User-Facing Changes `[[a a]; [1 2]]` will now return an error: ``` Error: nu::shell::column_defined_twice × Record field or table column used twice ╭─[entry nushell#2:1:1] 1 │ [[a a]; [1 2]] · ┬ ┬ · │ ╰── field redefined here · ╰── field first defined here ╰──── ``` this may under rare circumstances block code from evaluating. Furthermore this makes some NUON files invalid if they previously contained tables with repeated column names. # Tests + Formatting Added tests for each of the different evaluation paths that materialize tables.
hardfau1t
pushed a commit
to hardfau1t/nushell
that referenced
this pull request
Dec 14, 2023
nushell#10851) # Description Fixes: nushell#10271 Given the following script: ```shell # test.sh echo aaaaa echo bbbbb 1>&2 echo cc ``` This pr makes the following command possible: ```nushell bash test.sh err> /dev/null | lines | each {|line| $line | str length} ``` ## General idea behind the change: When nushell redirect stderr message to external file 1. it take stdout of external stream, and pass this stream to next command, so it won't block next pipeline command from running. 2. relative stderr stream are handled by `save` command These two streams are handled separately, so we need to delegate a thread to `save` command, or else we'll have a chance to hang nushell, we have meet a similar before: nushell#5625. ### One case to consider What if we're failed to save to an external stream? (Like we don't have a permission to save to a file)? In this case nushell will just print a waning message, and don't stop the following scripts from running. # User-Facing Changes ## Before ```nushell ❯ bash test2.sh err> /dev/null | lines | each {|line| $line | str length} aaaaa cc ``` ## After ```nushell ❯ bash test2.sh err> /dev/null | lines | each {|line| $line | str length} ╭───┬───╮ │ 0 │ 5 │ │ 1 │ 2 │ ╰───┴───╯ ``` BTY, after this pr, the following commands are impossible either, it's important to make sure that the implementation doesn't introduce too much costs: ```nushell ❯ echo a e> a.txt e> a.txt Error: × Can't make stderr redirection twice ╭─[entry #1:1:1] 1 │ echo a e> a.txt e> a.txt · ─┬ · ╰── try to remove one ╰──── ❯ echo a o> a.txt o> a.txt Error: × Can't make stdout redirection twice ╭─[entry nushell#2:1:1] 1 │ echo a o> a.txt o> a.txt · ─┬ · ╰── try to remove one ╰──── ```
hardfau1t
pushed a commit
to hardfau1t/nushell
that referenced
this pull request
Dec 14, 2023
Goes towards implementing nushell#10598, which asks for a spread operator in lists, in records, and when calling commands (continuation of nushell#11006, which only implements it in lists) # Description This PR is for adding a spread operator that can be used when building records. Additional functionality can be added later. Changes: - Previously, the `Expr::Record` variant held `(Expression, Expression)` pairs. It now holds instances of an enum `RecordItem` (the name isn't amazing) that allows either a key-value mapping or a spread operator. - `...` will be treated as the spread operator when it appears before `$`, `{`, or `(` inside records (no whitespace allowed in between) (not implemented yet) - The error message for duplicate columns now includes the column name itself, because if two spread records are involved in such an error, you can't tell which field was duplicated from the spans alone `...` will still be treated as a normal string outside records, and even in records, it is not treated as a spread operator when not followed immediately by a `$`, `{`, or `(`. # User-Facing Changes Users will be able to use `...` when building records. ``` > let rec = { x: 1, ...{ a: 2 } } > $rec ╭───┬───╮ │ x │ 1 │ │ a │ 2 │ ╰───┴───╯ > { foo: bar, ...$rec, baz: blah } ╭─────┬──────╮ │ foo │ bar │ │ x │ 1 │ │ a │ 2 │ │ baz │ blah │ ╰─────┴──────╯ ``` If you want to update a field of a record, you'll have to use `merge` instead: ``` > { ...$rec, x: 5 } Error: nu::shell::column_defined_twice × Record field or table column used twice: x ╭─[entry nushell#2:1:1] 1 │ { ...$rec, x: 5 } · ──┬─ ┬ · │ ╰── field redefined here · ╰── field first defined here ╰──── > $rec | merge { x: 5 } ╭───┬───╮ │ x │ 5 │ │ a │ 2 │ ╰───┴───╯ ``` # Tests + Formatting # After Submitting
hardfau1t
pushed a commit
to hardfau1t/nushell
that referenced
this pull request
Dec 14, 2023
) # Description Fixes: nushell#11143 # User-Facing Changes Take the following as example: ```nushell module foo { export def bar [] {}; export def baz [] {} } ``` `use foo bar baz` will be error: ``` ❯ use foo c d Error: nu::parser::wrong_import_pattern × Wrong import pattern structure. ╭─[entry nushell#2:1:1] 1 │ use foo c d · ┬ · ╰── Trying to import something but the parent `c` is not a module, maybe you want to try `use <module> [<name1>, <name2>]` ╰──── ``` # Tests + Formatting Done
hardfau1t
pushed a commit
to hardfau1t/nushell
that referenced
this pull request
Dec 14, 2023
this will allow to run ```nushell format date --list | get 0 ``` and get ``` ─────────────┬─────────────────────────────────────────────────────────── Specification│%Y Example │2023 Description │The full proleptic Gregorian year, zero-padded to 4 digits. ─────────────┴─────────────────────────────────────────────────────────── ``` instead of currently ``` Error: nu::parser::input_type_mismatch × Command does not support string input. ╭─[entry nushell#2:1:1] 1 │ format date --list | get 0 · ─┬─ · ╰── command doesn't support string input ╰──── ```
amtoine
pushed a commit
that referenced
this pull request
Dec 27, 2023
# Description
Currently, when writing a record, if you don't give the value for a
field, the syntax error highlights the entire record instead of
pinpointing the issue. Here's some examples:
```nushell
> { a: 2, 3 } # Missing colon (and value)
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry #2:1:1]
1 │ { a: 2, 3 }
· ─────┬─────
· ╰── expected record
╰────
> { a: 2, 3: } # Missing value
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry #3:1:1]
1 │ { a: 2, 3: }
· ──────┬─────
· ╰── expected record
╰────
> { a: 2, 3 4 } # Missing colon
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry #4:1:1]
1 │ { a: 2, 3 4 }
· ──────┬──────
· ╰── expected record
╰────
```
In all of them, the entire record is highlighted red because an
`Expr::Garbage` is returned covering that whole span:
This PR is for highlighting only the part inside the record that could
not be parsed. If the record literal is big, an error message pointing
to the start of where the parser thinks things went wrong should help
people fix their code.
# User-Facing Changes
Below are screenshots of the new errors:
If there's a stray record key right before the record ends, it
highlights only that key and tells the user it expected a colon after
it:
If the record ends before the value for the last field was given, it
highlights the key and colon of that field and tells the user it
expected a value after the colon:
If there are two consecutive expressions without a colon between them,
it highlights everything from the second expression to the end of the
record and tells the user it expected a colon. I was tempted to add a
help message suggesting adding a colon in between, but that may not
always be the right thing to do.
# Tests + Formatting
# After Submitting
WindSoilder
added a commit
that referenced
this pull request
Jan 25, 2024
# Description This is a follow up to: #11365 After this pr, `--flag: bool` is no longer allowed. I think `ParseWarning::Deprecated` is useful when we want to deprecated something at syntax level, so I just leave it there for now. # User-Facing Changes ## Before ``` ❯ def foo [--b: bool] {} Error: × Deprecated: --flag: bool ╭─[entry #15:1:1] 1 │ def foo [--b: bool] {} · ──┬─ · ╰── `--flag: bool` is deprecated and will be removed in 0.90. Please use `--flag` instead, more info: https://www.nushell.sh/book/custom_commands.html ╰──── ``` ## After ``` ❯ def foo [--b: bool] {} Error: × Type annotations are not allowed for boolean switches. ╭─[entry #2:1:1] 1 │ def foo [--b: bool] {} · ──┬─ · ╰── Remove the `: bool` type annotation. ╰──── ``` # Tests + Formatting Done
fdncred
added a commit
that referenced
this pull request
Feb 3, 2024
…r ints (#11724) # Description This PR changes `into int` and `into filesize` so that they allow thousands separators. ### Before ```nushell ❯ '1,000' | into filesize Error: nu::shell::cant_convert × Can't convert to int. ╭─[entry #1:1:1] 1 │ '1,000' | into filesize · ───┬─── · ╰── can't convert string to int ╰──── ❯ '1,000' | into int Error: nu:🐚:cant_convert × Can't convert to int. ╭─[entry #2:1:1] 1 │ '1,000' | into int · ────┬─── · ╰── can't convert string to int ╰──── help: string "1,000" does not represent a valid integer ``` ### After ```nushell ❯ '1,000' | into filesize 1.0 KB ❯ '1,000' | into int 1000 ``` This works by getting the system locale and from that, determining what the thousands separator is. So, hopefully, this will work across locales. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
WindSoilder
added a commit
that referenced
this pull request
Feb 8, 2024
# Description Close: #9673 Close: #8277 Close: #10944 This pr introduces the following syntax: 1. `e>|`, pipe stderr to next command. Example: `$env.FOO=bar nu --testbin echo_env_stderr FOO e>| str length` 2. `o+e>|` and `e+o>|`, pipe both stdout and stderr to next command, example: `$env.FOO=bar nu --testbin echo_env_mixed out-err FOO FOO e+o>| str length` Note: it only works for external commands. ~There is no different for internal commands, that is, the following three commands do the same things:~ Edit: it raises errors if we want to pipes for internal commands ``` ❯ ls e>| str length Error: × `e>|` only works with external streams ╭─[entry #1:1:1] 1 │ ls e>| str length · ─┬─ · ╰── `e>|` only works on external streams ╰──── ❯ ls e+o>| str length Error: × `o+e>|` only works with external streams ╭─[entry #2:1:1] 1 │ ls e+o>| str length · ──┬── · ╰── `o+e>|` only works on external streams ╰──── ``` This can help us to avoid some strange issues like the following: `$env.FOO=bar (nu --testbin echo_env_stderr FOO) e>| str length` Which is hard to understand and hard to explain to users. # User-Facing Changes Nan # Tests + Formatting To be done # After Submitting Maybe update documentation about these syntax.
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
# Description Pretty much all operations/commands in Nushell assume that the column names/keys in a record and thus also in a table (which consists of a list of records) are unique. Access through a string-like cell path should refer to a single column or key/value pair and our output through `table` will only show the last mention of a repeated column name. ```nu [[a a]; [1 2]] ╭─#─┬─a─╮ │ 0 │ 2 │ ╰───┴───╯ ``` While the record parsing already either errors with the `ShellError::ColumnDefinedTwice` or silently overwrites the first occurence with the second occurence, the table literal syntax `[[header columns]; [val1 val2]]` currently still allowed the creation of tables (and internally records with more than one entry with the same name. This is not only confusing, but also breaks some assumptions around how we can efficiently perform operations or in the past lead to outright bugs (e.g. nushell#8431 fixed by nushell#8446). This PR proposes to make this an error. After this change another hole which allowed the construction of records with non-unique column names will be plugged. ## Parts - Fix `SE::ColumnDefinedTwice` error code - Remove previous tests permitting duplicate columns - Deny duplicate column in table literal eval - Deny duplicate column in const eval - Deny duplicate column in `from nuon` # User-Facing Changes `[[a a]; [1 2]]` will now return an error: ``` Error: nu::shell::column_defined_twice × Record field or table column used twice ╭─[entry nushell#2:1:1] 1 │ [[a a]; [1 2]] · ┬ ┬ · │ ╰── field redefined here · ╰── field first defined here ╰──── ``` this may under rare circumstances block code from evaluating. Furthermore this makes some NUON files invalid if they previously contained tables with repeated column names. # Tests + Formatting Added tests for each of the different evaluation paths that materialize tables.
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
nushell#10851) # Description Fixes: nushell#10271 Given the following script: ```shell # test.sh echo aaaaa echo bbbbb 1>&2 echo cc ``` This pr makes the following command possible: ```nushell bash test.sh err> /dev/null | lines | each {|line| $line | str length} ``` ## General idea behind the change: When nushell redirect stderr message to external file 1. it take stdout of external stream, and pass this stream to next command, so it won't block next pipeline command from running. 2. relative stderr stream are handled by `save` command These two streams are handled separately, so we need to delegate a thread to `save` command, or else we'll have a chance to hang nushell, we have meet a similar before: nushell#5625. ### One case to consider What if we're failed to save to an external stream? (Like we don't have a permission to save to a file)? In this case nushell will just print a waning message, and don't stop the following scripts from running. # User-Facing Changes ## Before ```nushell ❯ bash test2.sh err> /dev/null | lines | each {|line| $line | str length} aaaaa cc ``` ## After ```nushell ❯ bash test2.sh err> /dev/null | lines | each {|line| $line | str length} ╭───┬───╮ │ 0 │ 5 │ │ 1 │ 2 │ ╰───┴───╯ ``` BTY, after this pr, the following commands are impossible either, it's important to make sure that the implementation doesn't introduce too much costs: ```nushell ❯ echo a e> a.txt e> a.txt Error: × Can't make stderr redirection twice ╭─[entry nushell#1:1:1] 1 │ echo a e> a.txt e> a.txt · ─┬ · ╰── try to remove one ╰──── ❯ echo a o> a.txt o> a.txt Error: × Can't make stdout redirection twice ╭─[entry nushell#2:1:1] 1 │ echo a o> a.txt o> a.txt · ─┬ · ╰── try to remove one ╰──── ```
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
Goes towards implementing nushell#10598, which asks for a spread operator in lists, in records, and when calling commands (continuation of nushell#11006, which only implements it in lists) # Description This PR is for adding a spread operator that can be used when building records. Additional functionality can be added later. Changes: - Previously, the `Expr::Record` variant held `(Expression, Expression)` pairs. It now holds instances of an enum `RecordItem` (the name isn't amazing) that allows either a key-value mapping or a spread operator. - `...` will be treated as the spread operator when it appears before `$`, `{`, or `(` inside records (no whitespace allowed in between) (not implemented yet) - The error message for duplicate columns now includes the column name itself, because if two spread records are involved in such an error, you can't tell which field was duplicated from the spans alone `...` will still be treated as a normal string outside records, and even in records, it is not treated as a spread operator when not followed immediately by a `$`, `{`, or `(`. # User-Facing Changes Users will be able to use `...` when building records. ``` > let rec = { x: 1, ...{ a: 2 } } > $rec ╭───┬───╮ │ x │ 1 │ │ a │ 2 │ ╰───┴───╯ > { foo: bar, ...$rec, baz: blah } ╭─────┬──────╮ │ foo │ bar │ │ x │ 1 │ │ a │ 2 │ │ baz │ blah │ ╰─────┴──────╯ ``` If you want to update a field of a record, you'll have to use `merge` instead: ``` > { ...$rec, x: 5 } Error: nu::shell::column_defined_twice × Record field or table column used twice: x ╭─[entry nushell#2:1:1] 1 │ { ...$rec, x: 5 } · ──┬─ ┬ · │ ╰── field redefined here · ╰── field first defined here ╰──── > $rec | merge { x: 5 } ╭───┬───╮ │ x │ 5 │ │ a │ 2 │ ╰───┴───╯ ``` # Tests + Formatting # After Submitting
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
) # Description Fixes: nushell#11143 # User-Facing Changes Take the following as example: ```nushell module foo { export def bar [] {}; export def baz [] {} } ``` `use foo bar baz` will be error: ``` ❯ use foo c d Error: nu::parser::wrong_import_pattern × Wrong import pattern structure. ╭─[entry nushell#2:1:1] 1 │ use foo c d · ┬ · ╰── Trying to import something but the parent `c` is not a module, maybe you want to try `use <module> [<name1>, <name2>]` ╰──── ``` # Tests + Formatting Done
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
this will allow to run ```nushell format date --list | get 0 ``` and get ``` ─────────────┬─────────────────────────────────────────────────────────── Specification│%Y Example │2023 Description │The full proleptic Gregorian year, zero-padded to 4 digits. ─────────────┴─────────────────────────────────────────────────────────── ``` instead of currently ``` Error: nu::parser::input_type_mismatch × Command does not support string input. ╭─[entry nushell#2:1:1] 1 │ format date --list | get 0 · ─┬─ · ╰── command doesn't support string input ╰──── ```
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
# Description
Currently, when writing a record, if you don't give the value for a
field, the syntax error highlights the entire record instead of
pinpointing the issue. Here's some examples:
```nushell
> { a: 2, 3 } # Missing colon (and value)
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry nushell#2:1:1]
1 │ { a: 2, 3 }
· ─────┬─────
· ╰── expected record
╰────
> { a: 2, 3: } # Missing value
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry nushell#3:1:1]
1 │ { a: 2, 3: }
· ──────┬─────
· ╰── expected record
╰────
> { a: 2, 3 4 } # Missing colon
Error: nu::parser::parse_mismatch
× Parse mismatch during operation.
╭─[entry nushell#4:1:1]
1 │ { a: 2, 3 4 }
· ──────┬──────
· ╰── expected record
╰────
```
In all of them, the entire record is highlighted red because an
`Expr::Garbage` is returned covering that whole span:
This PR is for highlighting only the part inside the record that could
not be parsed. If the record literal is big, an error message pointing
to the start of where the parser thinks things went wrong should help
people fix their code.
# User-Facing Changes
Below are screenshots of the new errors:
If there's a stray record key right before the record ends, it
highlights only that key and tells the user it expected a colon after
it:
If the record ends before the value for the last field was given, it
highlights the key and colon of that field and tells the user it
expected a value after the colon:
If there are two consecutive expressions without a colon between them,
it highlights everything from the second expression to the end of the
record and tells the user it expected a colon. I was tempted to add a
help message suggesting adding a colon in between, but that may not
always be the right thing to do.
# Tests + Formatting
# After Submitting
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
# Description This is a follow up to: nushell#11365 After this pr, `--flag: bool` is no longer allowed. I think `ParseWarning::Deprecated` is useful when we want to deprecated something at syntax level, so I just leave it there for now. # User-Facing Changes ## Before ``` ❯ def foo [--b: bool] {} Error: × Deprecated: --flag: bool ╭─[entry nushell#15:1:1] 1 │ def foo [--b: bool] {} · ──┬─ · ╰── `--flag: bool` is deprecated and will be removed in 0.90. Please use `--flag` instead, more info: https://www.nushell.sh/book/custom_commands.html ╰──── ``` ## After ``` ❯ def foo [--b: bool] {} Error: × Type annotations are not allowed for boolean switches. ╭─[entry nushell#2:1:1] 1 │ def foo [--b: bool] {} · ──┬─ · ╰── Remove the `: bool` type annotation. ╰──── ``` # Tests + Formatting Done
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
…r ints (nushell#11724) # Description This PR changes `into int` and `into filesize` so that they allow thousands separators. ### Before ```nushell ❯ '1,000' | into filesize Error: nu::shell::cant_convert × Can't convert to int. ╭─[entry nushell#1:1:1] 1 │ '1,000' | into filesize · ───┬─── · ╰── can't convert string to int ╰──── ❯ '1,000' | into int Error: nu:🐚:cant_convert × Can't convert to int. ╭─[entry nushell#2:1:1] 1 │ '1,000' | into int · ────┬─── · ╰── can't convert string to int ╰──── help: string "1,000" does not represent a valid integer ``` ### After ```nushell ❯ '1,000' | into filesize 1.0 KB ❯ '1,000' | into int 1000 ``` This works by getting the system locale and from that, determining what the thousands separator is. So, hopefully, this will work across locales. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
dmatos2012
pushed a commit
to dmatos2012/nushell
that referenced
this pull request
Feb 20, 2024
# Description Close: nushell#9673 Close: nushell#8277 Close: nushell#10944 This pr introduces the following syntax: 1. `e>|`, pipe stderr to next command. Example: `$env.FOO=bar nu --testbin echo_env_stderr FOO e>| str length` 2. `o+e>|` and `e+o>|`, pipe both stdout and stderr to next command, example: `$env.FOO=bar nu --testbin echo_env_mixed out-err FOO FOO e+o>| str length` Note: it only works for external commands. ~There is no different for internal commands, that is, the following three commands do the same things:~ Edit: it raises errors if we want to pipes for internal commands ``` ❯ ls e>| str length Error: × `e>|` only works with external streams ╭─[entry nushell#1:1:1] 1 │ ls e>| str length · ─┬─ · ╰── `e>|` only works on external streams ╰──── ❯ ls e+o>| str length Error: × `o+e>|` only works with external streams ╭─[entry nushell#2:1:1] 1 │ ls e+o>| str length · ──┬── · ╰── `o+e>|` only works on external streams ╰──── ``` This can help us to avoid some strange issues like the following: `$env.FOO=bar (nu --testbin echo_env_stderr FOO) e>| str length` Which is hard to understand and hard to explain to users. # User-Facing Changes Nan # Tests + Formatting To be done # After Submitting Maybe update documentation about these syntax.
IanManske
pushed a commit
to IanManske/nushell
that referenced
this pull request
Apr 26, 2024
Merge from main
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds our own helper so that we can force color prompts and get the length calculated off of the uncolored one.