forked from nushell/nushell
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/8755/config ref file #2
Closed
Closed
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
ito-hiroki
pushed a commit
that referenced
this pull request
Aug 20, 2023
# Description until now, a call to `toolkit` alone would give ```bash Error: nu::shell::external_command × External command failed ╭─[entry #2:1:1] 1 │ toolkit · ───┬─── · ╰── did you mean 'toolkit clippy'? ╰──── help: No such file or directory (os error 2) ``` which i find confusing after a `use toolkit.nu` 🤔 this PR adds a `main` command to `toolkit.nu` which runs the `help` command on the module. # User-Facing Changes now ``` > use toolkit.nu > toolkit Usage: > toolkit Subcommands: toolkit check pr - run all the necessary checks and tests to submit a perfect PR toolkit clippy - check that you're using the standard code style toolkit fmt - check standard code formatting and apply the changes toolkit setup-git-hooks - set up git hooks to run: - `toolkit fmt --check --verbose` on `git commit` - `toolkit fmt --check --verbose` and `toolkit clippy --verbose` on `git push` toolkit test - check that all the tests pass toolkit test stdlib - run the tests for the standard library Flags: -h, --help - Display the help message for this command ``` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting ``` $nothing ```
ito-hiroki
pushed a commit
that referenced
this pull request
Aug 20, 2023
# Description ## ❌ before this PR ``` >_ std help modules euwioq Error: nu:🐚:external_command × External command failed ╭─[help:259:1] 259 │ if ($found_module | is-empty) { 260 │ module_not_found_error (metadata $module | get span) · ──────────────┬────────────── · ╰── Cannot convert record<start: int, end: int> to a string 261 │ } ╰──── help: All arguments to an external command need to be string-compatible ``` ``` >_ std help externs euwioq Error: × std::help::extern_not_found ╭─[help:401:1] 401 │ 402 │ let extern = ($extern | str join " ") · ─┬─ · ╰── extern not found 403 │ ╰──── ``` > **Note** > same kind of error with all the others ## ✔️ after this PR ``` > std help modules euwioq 04/28/2023 05:45:50 PM Error: × std::help::module_not_found ╭─[entry #2:1:1] 1 │ std help modules euwioq · ───┬── · ╰── module not found ╰──── ``` ``` > std help externs euwioq 04/28/2023 05:45:53 PM Error: × std::help::extern_not_found ╭─[entry nushell#3:1:1] 1 │ std help externs euwioq · ───┬── · ╰── extern not found ╰──── ``` > **Note** > same with the others # User-Facing Changes fixes the errors to have proper messages # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting ``` $nothing ```
ito-hiroki
pushed a commit
that referenced
this pull request
Aug 20, 2023
related to - nushell#9101 - nushell#9039 # Description i actually forgot to fix in nushell#9039 the new "*item*" introduced by nushell#9101... 👀 there it is 😇 # User-facing changes going from ``` > std help git-commiteuwqi Help pages from external command git-commiteuwqi: No manual entry for git-commiteuwqi Error: × std::help::item_not_found ╭─[help:721:1] 721 │ 722 │ let item = ($item | str join " ") · ─┬─ · ╰── item not found 723 │ ╰──── ``` to ``` > std help git-commiteuwqi Help pages from external command git-commiteuwqi: No manual entry for git-commiteuwqi Error: × std::help::item_not_found ╭─[entry #2:1:1] 1 │ std help git-commiteuwqi · ───────┬─────── · ╰── item not found ╰──── ``` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting ``` $nothing ```
ito-hiroki
pushed a commit
that referenced
this pull request
Aug 20, 2023
# Description Fixes a small bug with `rm` where names of files which couldn't be deleted due to error were not printed. Fixes nushell#9004 # User-Facing Changes Slightly different error message than previously. Nothing significant, though. The new error message looks like this ``` ~/Projects/rust/nushell> rm /proc/1/mem 05/06/2023 01:13:23 PM Error: nu::shell::remove_not_possible × Remove not possible ╭─[entry nushell#3:1:1] 1 │ rm /proc/1/mem · ─────┬───── · ╰── Could not delete /proc/1/mem: Operation not permitted (os error 1) ╰──── ``` or when using a glob (only showing a single entry for brevity) ``` Error: nu:🐚:remove_not_possible × Remove not possible ╭─[entry #2:1:1] 1 │ rm --recursive --force --verbose /proc/1/* · ────┬──── · ╰── Could not delete /proc/1/comm: Operation not permitted (os error 1) ╰──── ``` # Tests + Formatting No new unit tests were added for this change as it is pretty difficult to test this particular case. However, manual testing was run with the following commands ``` rm /proc/1/mem rm --recursive --force --verbose /proc/1/* ``` # After Submitting N/A
ito-hiroki
pushed a commit
that referenced
this pull request
Aug 20, 2023
# Description in the help page of `metadata`, there is the following example ```nushell ls | metadata ``` which gives the following error ``` Error: nu::parser::input_type_mismatch × Command does not support table input. ╭─[entry #2:1:1] 1 │ ls | metadata · ────┬─── · ╰── command doesn't support table input ╰──── ``` this PR adds `any -> record` to the signatures of `metadata` to allow the use of that kind of example. # User-Facing Changes `ls | metadata` will work again # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting
ito-hiroki
pushed a commit
that referenced
this pull request
Aug 20, 2023
# Description This PR updates the `items` command to allow `any` output. items takes a closure so theoretically, any value type of output could be valid. ### Before ```nushell {a: 1 b: 2} | items {|k,v| {key: $k value: $v}} | transpose Error: nu::parser::input_type_mismatch × Command does not support list<string> input. ╭─[entry #2:1:1] 1 │ {a: 1 b: 2} | items {|k,v| {key: $k value: $v}} | transpose · ────┬──── · ╰── command doesn't support list<string> input ╰──── ``` ### After ```nushell ❯ {a: 1 b: 2} | items {|k,v| {key: $k value: $v}} | transpose ╭───┬─────────┬─────────┬─────────╮ │ # │ column0 │ column1 │ column2 │ ├───┼─────────┼─────────┼─────────┤ │ 0 │ key │ a │ b │ │ 1 │ value │ 1 │ 2 │ ╰───┴─────────┴─────────┴─────────╯ ``` # 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 -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `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. -->
ito-hiroki
pushed a commit
that referenced
this pull request
Aug 20, 2023
# Description This PR changes the signature of the deprecated command `let-env` so that it does not mislead people when invoking it without parameters. ### Before ```nushell > let-env Error: nu::parser::missing_positional × Missing required positional argument. ╭─[entry #2:1:1] 1 │ let-env ╰──── help: Usage: let-env <var_name> = <initial_value> ``` ### After ```nushell ❯ let-env Error: nu:🐚:deprecated_command × Deprecated command let-env ╭─[entry #1:1:1] 1 │ let-env · ───┬─── · ╰── 'let-env' is deprecated. Please use '$env.<environment variable> = ...' instead. ╰──── ``` # 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 -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `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. -->
ito-hiroki
pushed a commit
that referenced
this pull request
Oct 14, 2023
- Hopefully closes nushell#10120 # Description This PR adds a new config item, `error_style`. It will render errors in a screen reader friendly mode when set to `"simple"`. This is done using `miette`'s own `NarratableReportHandler`, which seamlessly replaces the default one when needed. Before: ``` Error: nu::shell::external_command × External command failed ╭─[entry #2:1:1] 1 │ doesnt exist · ───┬── · ╰── executable was not found ╰──── help: No such file or directory (os error 2) ``` After: ``` Error: External command failed Diagnostic severity: error Begin snippet for entry nushell#4 starting at line 1, column 1 snippet line 1: doesnt exist label at line 1, columns 1 to 6: executable was not found diagnostic help: No such file or directory (os error 2) diagnostic code: nu::shell::external_command ``` ## Things to be determined - ~Review naming. `errors.style` is not _that_ consistent with the rest of the code. Menus use a `style` record, but table rendering mode is set via `mode`.~ As it's a single config, we're using `error_style` for now. - Should this kind of setting be toggable with one single parameter? `accessibility.no_decorations` or similar, which would adjust the style of both errors and tables accordingly. # User-Facing Changes No changes by default, errors will be rendered differently if `error_style` is set to `simple`. # 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 There's a PR updating the docs over here nushell/nushell.github.io#1026
ito-hiroki
pushed a commit
that referenced
this pull request
Oct 14, 2023
related to - https://discord.com/channels/601130461678272522/615329862395101194/1149717458786197524 # Description because `1_234 | into datetime` takes an integer number of `ns` and `1_234 | into filesize` takes an integer amount of bytes, i think `1_234 | into duration` should also be valid and see `1_234` as an integer amount of `ns` 😋 # User-Facing Changes ## before either ```nushell 1234 | into string | $in ++ "ns" | into duration ``` ```nushell 1234 | $"($in)ns" | into duration ``` or ```nushell 1234 * 1ns ``` and ```nushell > 1_234 | into duration Error: nu::parser::input_type_mismatch × Command does not support int input. ╭─[entry #2:1:1] 1 │ 1_234 | into duration · ──────┬────── · ╰── command doesn't support int input ╰──── ``` ## after ```nushell > 1_234 | into duration 1µs 234ns ``` # Tests + Formatting new example test ```rust Example { description: "Convert a number of ns to duration", example: "1_234_567 | into duration", result: Some(Value::duration(1_234_567, span)), } ``` # After Submitting
ito-hiroki
pushed a commit
that referenced
this pull request
Oct 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 #2:1:1] 1 │ ^echo "foo" | get 0 · ──┬─ · ╰── external stream doesn't support cell paths ╰──── ``` # Tests + Formatting # After Submitting
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 2024
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 #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
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #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.
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #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 ╰──── ```
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #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
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #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
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #2:1:1] 1 │ format date --list | get 0 · ─┬─ · ╰── command doesn't support string input ╰──── ```
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #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: ![image](https://github.com/nushell/nushell/assets/45539777/36660b50-23be-4353-b180-3f84eff3c220) 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: ![image](https://github.com/nushell/nushell/assets/45539777/94503256-8ea2-47dd-b69a-4b520c66f7b6) 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: ![image](https://github.com/nushell/nushell/assets/45539777/2f3837ec-3b35-4b81-8c57-706f8056ac04) 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. ![image](https://github.com/nushell/nushell/assets/45539777/1abaaaa8-1896-4909-bbb7-9a38cece5250) # Tests + Formatting # After Submitting
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #2:1:1] 1 │ def foo [--b: bool] {} · ──┬─ · ╰── Remove the `: bool` type annotation. ╰──── ``` # Tests + Formatting Done
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #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. -->
ito-hiroki
pushed a commit
that referenced
this pull request
May 7, 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 #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.
ito-hiroki
pushed a commit
that referenced
this pull request
Jun 29, 2024
…ushell#13131) # Description Closes: nushell#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
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.
Description
(Thank you for improving Nushell. Please, check our contributing guide and talk to the core team before making major changes.)
(Description of your pull request goes here. Provide examples and/or screenshots if your changes affect the user experience.)
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 stylecargo test --workspace
to check that all tests passcargo run -- crates/nu-utils/standard_library/tests.nu
to run the tests for the standard libraryAfter Submitting
If your PR had any user-facing changes, update the documentation after the PR is merged, if necessary. This will help us keep the docs up to date.