Test/stdlib in the ci by amtoine · Pull Request #1 · amtoine/nushell

amtoine · 2023-03-19T08:28:24Z

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 style
cargo test --workspace to check that all tests pass

Note
from nushell you can also use the toolkit as follows
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 after the PR is merged, if necessary. This will help us keep the docs up to date.

```bash >_ NU_LOG_LEVEL=DEBUG nu crates/nu-utils/standard_library/tests.nu INFO Run tests in test_dirs module DEBUG Run test test_dirs test_dirs_command INFO Run tests in test_logger module DEBUG Run test test_logger test_critical DEBUG Run test test_logger test_debug DEBUG Run test test_logger test_error DEBUG Run test test_logger test_info DEBUG Run test test_logger test_warning INFO Run tests in test_std module DEBUG Run test test_std test_assert DEBUG Run test test_std test_match Error: × Assertion failed. ╭─[/home/amtoine/.local/share/git/store/github.com/amtoine/nushell/crates/nu-utils/standard_library/test_std.nu:37:1] 37 │ 38 │ assert ((std match 1 $branches { 0 }) == -10) · ───────────────────┬────────────────── · ╰── It is not true. 39 │ assert ((std match 2 $branches { 0 }) == -2) ╰──── ```

this allows the test runner to stop whenever there is a failing test and throw an `$env.LAST_EXIT_CODE` to `1`.

This reverts commit 98ec84a.

…ushell#8562) # Description Fixes: nushell#8548 # User-Facing Changes ``` ❯ register target/debug/formats Error: × Register plugin failed ╭─[entry #1:1:1] 1 │ register target/debug/formats · ──────────┬───────── · ╰── plugin name must starts with nu_plugin_ ╰──── ``` # 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

# Description @fdncred noticed an [issue](nushell#8529 (comment)) with list annotations that while i was trying to find a fix found another issue. innitially, this was accepted by the parser ```nu def err [list: list<int> = ['a' 'b' 'c']] {} ``` but now an error is raised ```nu Error: nu::parser::assignment_mismatch × Default value wrong type ╭─[entry #1:1:1] 1 │ def err [list: list<int> = ['a' 'b' 'c']] {} · ──────┬──── · ╰── expected default value to be `list<int>` ╰──── ``` # User-Facing Changes none # Tests + Formatting done

Should close nushell#8704. # Description this PR - makes the error thrown by things like `ansi -e {invalid: "invalid"}` more explicit - makes the `ansi -e` example more explicit about valid / invalid keys # User-Facing Changes the error ```bash > ansi -e {invalid: "invalid"} Error: nu::shell::incompatible_parameters × Incompatible parameters. ╭─[entry #1:1:1] 1 │ ansi -e {invalid: "invalid"} · ──────────┬───────── · ╰── unknown ANSI format key: expected one of ['fg', 'bg', 'attr'], found 'invalid' ╰──── ``` the new `ansi -e` example ```bash Use structured escape codes > let bold_blue_on_red = { # `fg`, `bg`, `attr` are the acceptable keys, all other keys are considered invalid and will throw errors. fg: '#0000ff' bg: '#ff0000' attr: b } $"(ansi -e $bold_blue_on_red)Hello Nu World(ansi reset)" Hello Nu World ``` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting ``` $nothing ```

# Description The "CREATE TABLE" statement in `into sqlite` does not add quotes to the column names, reproduction steps are below: ``` /home/xxx〉[[name,y/n];[a,y]] | into sqlite test.db Error: × Failed to prepare SQLite statement ╭─[entry #1:1:1] 1 │ [[name,y/n];[a,y]] | into sqlite test.db · ───┬─── · ╰── near "/": syntax error in CREATE TABLE IF NOT EXISTS main (name TEXT,y/n TEXT) at offset 44 ╰──── ``` # User-Facing Changes None --------- Co-authored-by: Reilly Wood <reilly.wood@icloud.com>

…ushell#8274) # Description Fixes: nushell#7575 # User-Facing Changes Previously: ``` if❯ if false { "aaa" } else if $a { 'a' } Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry nushell#10:1:1] 1 │ if false { "aaa" } else if $a { 'a' } · ─┬ · ╰── expected block, closure or record ╰──── ``` After: ``` ❯ if false { "aaa" } else if $a { 'a' } Error: nu::parser::variable_not_found × Variable not found. ╭─[entry #1:1:1] 1 │ if false { "aaa" } else if $a { 'a' } · ─┬ · ╰── variable not found ╰──── ``` # Tests + Formatting Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass # After Submitting If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date.

…ll#8958) # Description closes nushell#8934 this pr improves the diagnostic emitted when the name and parameters of either `def`, `def-env` or `extern` are not separated by a space ```nu Error: × no space between name and parameters ╭─[entry #1:1:1] 1 │ def err[] {} · ▲ · ╰── expected space ╰──── help: consider adding a space between the `def` command's name and its parameters ``` from ```nu Error: nu::parser::missing_positional × Missing required positional argument. ╭─[entry #1:1:1] 1 │ def err[] {} ╰──── help: Usage: def <def_name> <params> <body> ``` --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com> Co-authored-by: Jelle Besseling <jelle@pingiun.com>

related to the changes in - nushell#9193 # Description when we change the namespace of a module, the internal calls to the `export`ed commands needs to be updated as well 👀 😆 without this, we have the following pretty error: ``` > std help ansi Error: × std::help::item_not_found ╭─[entry #1:1:1] 1 │ std help ansi · ──┬─ · ╰── item not found ╰──── ```

# Description This PR improves the error message if an environment variable (that's visible before the parser begins) is used in the form of `$PATH` instead of `$env.PATH`. Before: ``` Error: nu::parser::variable_not_found × Variable not found. ╭─[entry nushell#31:1:1] 1 │ echo $PATH · ──┬── · ╰── variable not found. ╰──── ``` After: ``` Error: nu::parser::env_var_not_var × Use $env.PATH instead of $PATH. ╭─[entry #1:1:1] 1 │ echo $PATH · ──┬── · ╰── use $env.PATH instead of $PATH ╰──── ``` # User-Facing Changes Just the improvement to the error message # Tests + Formatting  # After Submitting

this solves the following error ``` error: proc-macro derive panicked --> crates/nu-cmd-extra/src/extra/formats/to/html.rs:79:10 | 79 | #[derive(RustEmbed)] | ^^^^^^^^^ | = help: message: #[derive(RustEmbed)] folder '/home/amtoine/.local/share/git/store/github.com/amtoine/nushell/crates/nu-cmd-extra/assets/' does not exist. cwd: '/home/amtoine/.local/share/git/store/github.com/amtoine/nushell' error[E0599]: no function or associated item named `get` found for struct `Assets` in the current scope --> crates/nu-cmd-extra/src/extra/formats/to/html.rs:228:19 | 81 | struct Assets; | ------------- function or associated item `get` not found for this struct ... 228 | match Assets::get(json_name) { | ^^^ function or associated item not found in `Assets` | = help: items from traits can only be used if the trait is implemented and in scope = note: the following traits define an item `get`, perhaps you need to implement one of them: candidate #1: `SliceIndex` candidate #2: `RustEmbed` For more information about this error, try `rustc --explain E0599`. error: could not compile `nu-cmd-extra` due to 2 previous errors warning: build failed, waiting for other jobs to finish... ```

# Description i have the following command that should give a table of all the mounted devices with information about their sizes, etc, etc... a glorified output for the `df -h` command: ```nushell def disk [] { df -h | str replace "Mounted on" "Mountpoint" | detect columns | rename filesystem size used avail used% mountpoint | into filesize size used avail | upsert used% {|it| 100 * (1 - $it.avail / $it.size)} } ``` this should work given the first example of `into filesize` ```nushell Convert string to filesize in table > [[bytes]; ['5'] [3.2] [4] [2kb]] | into filesize bytes ``` ## before this PR it does not even parse ```nushell Error: nu::parser::input_type_mismatch × Command does not support table input. ╭─[entry #1:5:1] 5 │ | rename filesystem size used avail used% mountpoint 6 │ | into filesize size used avail · ──────┬────── · ╰── command doesn't support table input 7 │ | upsert used% {|it| 100 * (1 - $it.avail / $it.size)} ╰──── ``` > **Note** > this was working before the recent input / output type changes ## with this PR it parses again and gives ```nushell > disk | where mountpoint == "/" | into record ╭────────────┬───────────────────╮ │ filesystem │ /dev/sda2 │ │ size │ 217.9 GiB │ │ used │ 158.3 GiB │ │ avail │ 48.4 GiB │ │ used% │ 77.77777777777779 │ │ mountpoint │ / │ ╰────────────┴───────────────────╯ ``` > **Note** > the two following commands also work now and did not before the PR > ```nushell > ls | insert name_size {|it| $it.name | str length} | into filesize name_size > ``` > ```nushell > [[device size]; ["/dev/sda1" 200] ["/dev/loop0" 50]] | into filesize size > ``` # User-Facing Changes `into filesize` works back with tables and this effectively fixes the doc. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` this PR gives a `result` back to the first table example to make sure it works fine. # After Submitting

# 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  # Tests + Formatting  # After Submitting

this avoids the following error ```nushell > {null: "foo"} Error: nu::shell::cant_convert × Can't convert to string. ╭─[entry #1:1:1] 1 │ {null: "foo"} · ──┬─ · ╰── can't convert nothing to string ╰──── ```

related to - https://discord.com/channels/601130461678272522/614593951969574961/1141009665266831470 # Description this PR - prints a colorful warning when a user uses either `--format` or `--list` on `into datetime` - does NOT remove the features for now, i.e. the two options still work - redirect to the `format date` command instead i propose to - land this now - prepare a removal PR right after this - land the removal PR in between 0.84 and 0.85 # User-Facing Changes `into datetime --format` and `into datetime --list` will be deprecated in 0.85. ## how it looks - `into datetime --list` in the REPL ```nushell > into datetime --list | first Error: × Deprecated option ╭─[entry #1:1:1] 1 │ into datetime --list | first · ──────┬────── · ╰── `into datetime --list` is deprecated and will be removed in 0.85 ╰──── help: see `format datetime --list` instead ╭───────────────┬────────────────────────────────────────────╮ │ Specification │ %Y │ │ Example │ 2023 │ │ Description │ The full proleptic Gregorian year, │ │ │ zero-padded to 4 digits. │ ╰───────────────┴────────────────────────────────────────────╯ ``` - `into datetime --list` in a script ```nushell > nu /tmp/foo.nu Error: × Deprecated option ╭─[/tmp/foo.nu:4:1] 4 │ # 5 │ into datetime --list | first · ──────┬────── · ╰── `into datetime --list` is deprecated and will be removed in 0.85 ╰──── help: see `format datetime --list` instead ╭───────────────┬────────────────────────────────────────────╮ │ Specification │ %Y │ │ Example │ 2023 │ │ Description │ The full proleptic Gregorian year, │ │ │ zero-padded to 4 digits. │ ╰───────────────┴────────────────────────────────────────────╯ ``` - `help into datetime` ![baz](https://github.com/nushell/nushell/assets/44101798/08beece0-9c89-4665-bfe4-76a32207470f) # Tests + Formatting # After Submitting

# Description We keep "into decimal" for a release and warn through a message that it will be removed in 0.86. All tests are updated to use `into float` # User-Facing Changes `into decimal` raises a deprecation warning, will be removed soon. Use `into float` as the new functionally identical command instead. ``` ~/nushell> 2 | into decimal Error: × Deprecated command ╭─[entry #1:1:1] 1 │ 2 | into decimal · ──────┬───── · ╰── `into decimal` is deprecated and will be removed in 0.86. ╰──── help: Use `into float` instead 2 ``` # Tests + Formatting Updated --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>

fixes nushell#8551 # Description Use `open::commands` function to get list of command available for starting given path. run commands directly, providing environment, until one of them is successful. example of output if start was not successful: ``` ~\code\nushell> start ..\nustart\a.myext 09/12/2023 01:37:55 PM Error: nu::shell::external_command × External command failed ╭─[entry #1:1:1] 1 │ start ..\nustart\a.myext · ─────────┬──────── · ╰── No command found to start with this path ╰──── help: Try different path or install appropriate command Command `cmd /c start "" "..\nustart\a.myext"` failed with exit code: 1 ``` # User-Facing Changes `start` command now provides environment to the external command. This is how it worked in `nu 0.72`, see linked issue. # Tests + Formatting `start` command didn't have any tests and this PR does not add any. Integration-level tests will require setup specific to OS and potentially change global environment on testing machine. For unit-level test it is possible to test `try_commands` function. But is still runs external commands, and robust test will require apriori knowledge which commands are necessary successful to run and which are not.

# Description This PR allows the `values` command to support lazy records. closes nushell#10417 ### Before ```nushell sys | values Error: nu::shell::only_supports_this_input_type × Input type not supported. ╭─[entry #1:1:1] 1 │ sys | values · ─┬─ ───┬── · │ ╰── only record or table input data is supported · ╰── input type: record<host: record<name: string, os_version: string, long_os_version: string, kernel_version: string, hostname: string, uptime: duration, boot_time: string, sessions: list<any>>, cpu: table<name: string, brand: string, freq: int, cpu_usage: float, load_average: string, vendor_id: string>, disks: table<device: string, type: string, mount: string, total: filesize, free: filesize, removable: bool, kind: string>, mem: record<total: filesize, free: filesize, used: filesize, available: filesize, swap total: filesize, swap free: filesize, swap used: filesize>, temp: list<any>, net: table<name: string, sent: filesize, recv: filesize>> ╰──── ``` ### After ```nushell ❯ sys | values ╭─┬─────────────────╮ │0│{record 8 fields}│ │1│[table 16 rows] │ │2│[table 1 row] │ │3│{record 7 fields}│ │4│[list 0 items] │ │5│[table 5 rows] │ ╰─┴─────────────────╯ ``` # User-Facing Changes  # Tests + Formatting  # After Submitting

@jntrnr

related to - nushell#9973 - nushell#9918 thanks to @jntrnr and their super useful tips on this PR, i learned about the parser + evaluation, so 🙏 # Description because we already have `null` as the value of the type `nothing` and as a followup to the two other attempts of mine, i propose to remove the redundant `$nothing` built-in variable 😋 this PR is the first step, deprecating `$nothing`. a followup PR will remove it altogether and wait for 0.87 👍 ⚙️ **details**: a new `NOTHING_VARIABLE_ID = 3` has been added, parsing `$nothing` will create it, finally a `Value::Nothing` will be produced and a warning will be reported. this PR already fixes the `toolkit.nu` module so that it does not throw a bunch of warnings each time 👌 # User-Facing Changes `$nothing` is now deprecated and will be removed in 0.87 ```nushell > $nothing Error: × Deprecated variable ╭─[entry #1:1:1] 1 │ $nothing · ────┬─── · ╰── `$nothing` is deprecated and will be removed in 0.87. ╰──── help: Use `null` instead ``` # Tests + Formatting tests have been updated, especially - `nothing_fails_string` - `nothing_fails_int` which use a variable called `nil` now to make sure `nothing` does not support cell paths 👍 # After Submitting classic deprecation mention 👍

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

follow-up to - nushell#10566 # Description this PR deprecates the use of `def-env` and `export def-env` these two core commands will be removed in 0.88 # User-Facing Changes using `def-env` will give a warning ```nushell > def-env foo [] { print "foo" }; foo Error: × Deprecated command ╭─[entry #1:1:1] 1 │ def-env foo [] { print "foo" }; foo · ───┬─── · ╰── `def-env` is deprecated and will be removed in 0.88. ╰──── help: Use `def --env` instead foo ``` # Tests + Formatting # After Submitting

related to - nushell#10478 # Description this PR is the followup removal to nushell#10478. # User-Facing Changes `$nothing` is now an undefined variable, unless define by the user. ```nushell > $nothing Error: nu::parser::variable_not_found × Variable not found. ╭─[entry #1:1:1] 1 │ $nothing · ────┬─── · ╰── variable not found. ╰──── ``` # Tests + Formatting # After Submitting mention that in release notes

related to - nushell#10520 # Description this PR is a followup to nushell#10520 and removes the `random integer` command completely, in favor of `random int`. # User-Facing Changes `random integer` has been fully moved to `random int` ```nushell > random integer 0..1 Error: nu::parser::extra_positional × Extra positional argument. ╭─[entry #1:1:1] 1 │ random integer 0..1 · ───┬─── · ╰── extra positional argument ╰──── help: Usage: random ``` # Tests + Formatting tests have been moved from `crates/nu-command/tests/commands/random/integer.rs` to `crates/nu-command/tests/commands/random/int.rs` # After Submitting mention in 0.87.0 release notes

# Description Fixes: nushell#10830 The issue happened during lite-parsing, when we want to put a `LiteElement` to a `LitePipeline`, we do nothing if relative redirection target is empty. So the command `echo aaa o> | ignore` will be interpreted to `echo aaa | ignore`. This pr is going to check and return an error if redirection target is empty. # User-Facing Changes ## Before ``` ❯ echo aaa o> | ignore # nothing happened ``` ## After ```nushell ❯ echo aaa o> | ignore Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #1:1:1] 1 │ echo aaa o> | ignore · ─┬ · ╰── expected redirection target ╰──── ```

Trying to call `metadata $env` or `metadata $nu` will throw an error: ```Nushell ~> metadata $nu Error: × Built-in variables `$env` and `$nu` have no metadata ╭─[entry #1:1:1] 1 │ metadata $nu · ─┬─ · ╰── no metadata available ╰──── ```

This fixes an issue brought up by nihilander in [Discord](https://discord.com/channels/601130461678272522/614593951969574961/1201594105986285649). # Description  Nushell panics when the spread operator is used like this (the `...$rest` shouldn't actually be parsed as a spread operator at all): ```nu $ def foo [...rest: string] {...$rest} $ foo bar baz thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/nu-protocol-0.89.0/src/signature.rs:650:9: Internal error: can't run a predeclaration without a body stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: <nu_protocol::signature::Predeclaration as nu_protocol::engine::command::Command>::run 3: nu_engine::eval::eval_call 4: nu_engine::eval::eval_expression_with_input 5: nu_engine::eval::eval_element_with_input 6: nu_engine::eval::eval_block 7: nu_cli::util::eval_source 8: nu_cli::repl::evaluate_repl 9: nu::run::run_repl 10: nu::main note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. ``` The problem was that whenever the parser saw something like `{...$`, `{...(`, or `{...[`, it would treat that as a record with a spread expression, ignoring the syntax shape of the block it was parsing. This should now be fixed, and the snippet above instead gives the following error: ```nu Error: nu::shell::external_command × External command failed ╭─[entry #1:1:1] 1 │ def foo [...rest] {...$rest} · ────┬─── · ╰── executable was not found ╰──── help: No such file or directory (os error 2) ``` # User-Facing Changes  Stuff like `do { ...$rest }` will now try to run a command `...$rest` rather than complaining that variable `$rest` doesn't exist. # Tests + Formatting  # After Submitting  Sorry about the issue, I am not touching the parser again for a long time :)

# Description  Fixes nushell#11711 Previously, syntax `def a [] (echo 4)` was allowed to parse and then failed with panic duting eval. Current error: ``` Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #1:1:1] 1 │ def a [] (echo 4) · ────┬─── · ╰── expected definition body closure { ... } ╰──── ``` # User-Facing Changes  # Tests + Formatting  # After Submitting

…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  # Tests + Formatting  # After Submitting

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

# Description Fix nushell#11732  # User-Facing Changes  Invalid output format causes an error, not a panic. ```nu ❯ seq date --output-format '%H-%M-%S' Error: × Invalid output format ╭─[entry #1:1:1] 1 │ seq date --output-format '%H-%M-%S' · ────┬─── · ╰── an error occurred when formatting an argument ╰──── ``` # Tests + Formatting  # After Submitting

fixes nushell#11783 # Description Firstly Tests for the `move` Command have been added. Afterwards some duplicate Code has been removed and finally an error-message has been added for when a column is tried to be moved based on itself. This should fix nushell#11783 . To reiterate, the example of the initial issue now plays out as follows: ```shell > {a: 1} | move a --after a Error: nu::shell::incompatible_parameters × Incompatible parameters. ╭─[entry #1:1:15] 1 │ {a: 1} | move a --after a · ┬ ┬ · │ ╰── relative to itself · ╰── Column cannot be moved ╰──── ``` # User-Facing Changes The error message shown above. # Tests + Formatting I added some Tests for the behavior of the command. If I should add more, please let me know but I added everything that came to mind when thinking about the command. --------- Co-authored-by: dannou812 <dannou281@gmail.com>

# Description After some iteration on globbing rules, I don't think `str escape-glob` is needed # User-Facing Changes ```nushell ❯ let f = "[ab]*.nu" ❯ $f | str escape-glob Error: × str escape-glob is deprecated ╭─[entry #1:1:6] 1 │ $f | str escape-glob · ───────┬─────── · ╰── if you are trying to escape a variable, you don't need to do it now ╰──── help: Remove `str escape-glob` call [[]ab[]][*].nu ``` # Tests + Formatting NaN # After Submitting NaN

# Description This PR fixes a globbing bug in the `du` command. The problem was that `--exclude` needed to be a `NuGlob` instead of a `String`. A variety of ways were tried to fix this, including spread operators and `into glob` but none of them worked. Here's the [Discord Conversation](https://discord.com/channels/601130461678272522/1214950311207243796/1214950311207243796) that documents the attempts. ### Before ```nushell ❯ du $env.PWD -x crates/** Error: nu::shell::cant_convert × Can't convert to string. ╭─[entry #1:1:16] 1 │ du $env.PWD -x crates/** · ────┬──── · ╰── can't convert glob to string ╰──── ``` ### After ```nushell ❯ du $env.PWD -x crates/** ╭─#─┬────path────┬apparent─┬physical─┬───directories───┬files╮ │ 0 │ D:\nushell │ 55.6 MB │ 55.6 MB │ [table 17 rows] │ │ ╰───┴────────────┴─────────┴─────────┴─────────────────┴─────╯ ```

# Description Resolves nushell#11274. ``` ~/CodingProjects/nushell> let day = 2; echo 0..<$day ╭───┬───╮ │ 0 │ 0 │ │ 1 │ 1 │ ╰───┴───╯ ~/CodingProjects/nushell> let kb = "jan"; echo 0..$kb Error: nu::shell::type_mismatch × Type mismatch during operation. ╭─[entry #1:1:22] 1 │ let kb = "jan"; echo 0..$kb · ┬─┬─┬─ · │ │ ╰── string · │ ╰── type mismatch for operator · ╰── int ╰──── ``` # Tests + Formatting Relevant test added 🆙 --------- Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>

# Description Resolves nushell#11756. Resolves nushell#12346. As per description, shell no longer hangs: ``` ~/CodingProjects/nushell> [1 2 3] | select (-2) Error: nu::shell::cant_convert × Can't convert to cell path. ╭─[entry #1:1:18] 1 │ [1 2 3] | select (-2) · ──┬─ · ╰── can't convert negative number to cell path ╰──── ```  # User-Facing Changes  # Tests + Formatting  Added relevant test 🚀 # After Submitting  Possibly support `get` `get`ting negative numbers, as per nushell#12346 discussion. Alternatively, we can consider adding a cellpath for negative indexing?

@maxim-uvarov

# Description From @maxim-uvarov's [post](https://discord.com/channels/601130461678272522/1227612017171501136/1228656319704203375). When calling `to-lazy` back to back in a pipeline, an error should not occur: ``` > [[a b]; [6 2] [1 4] [4 1]] | polars into-lazy | polars into-lazy Error: nu::shell::cant_convert × Can't convert to NuDataFrame. ╭─[entry #1:1:30] 1 │ [[a b]; [6 2] [1 4] [4 1]] | polars into-lazy | polars into-lazy · ────────┬─────── · ╰── can't convert NuLazyFrameCustomValue to NuDataFrame ╰──── ``` This pull request ensures that custom value's of NuLazyFrameCustomValue are properly converted when passed in. Co-authored-by: Jack Wright <jack.wright@disqo.com>

# Description Fixes nushell#12520 # User-Facing Changes Breaking change: Any operation parsing input with `PWD` to set the environment will now fail with `ShellError::AutomaticEnvVarSetManually` Furthermore transactions containing the special env-vars will be rejected before executing any modifications. Prevoiusly this was changing valid variables before while leaving valid variables after the violation untouched. ## `PWD` handling. Now failing ``` {PWD: "/trolling"} | load-env ``` already failing ``` load-env {PWD: "/trolling"} ``` ## Error management ``` > load-env {MY_VAR1: foo, PWD: "/trolling", MY_VAR2: bar} Error: nu::shell::automatic_env_var_set_manually × PWD cannot be set manually. ╭─[entry #1:1:2] 1 │ load-env {MY_VAR1: foo, PWD: "/trolling", MY_VAR2: bar} · ────┬─── · ╰── cannot set 'PWD' manually ╰──── help: The environment variable 'PWD' is set automatically by Nushell and cannot be set manually. ``` ### Before: ``` > $env.MY_VAR1 foo > $env.MY_VAR2 Error: nu:🐚:name_not_found .... ``` ### After: ``` > $env.MY_VAR1 Error: nu:🐚:name_not_found .... > $env.MY_VAR2 Error: nu:🐚:name_not_found .... ``` # After Submitting We need to check if any integrations rely on this hack.

@maxim-uvarov

…to eager frames later in the pipeline. (nushell#12525) # Description @maxim-uvarov discovered the following error: ``` > [[a b]; [6 2] [1 4] [4 1]] | polars into-lazy | polars sort-by a | polars unique --subset [a] Error: × Error using as series ╭─[entry #1:1:68] 1 │ [[a b]; [6 2] [1 4] [4 1]] | polars into-lazy | polars sort-by a | polars unique --subset [a] · ──────┬────── · ╰── dataframe has more than one column ╰──── ``` During investigation, I discovered the root cause was that the lazy frame was incorrectly converted back to a eager dataframe. In order to keep this from happening, I explicitly set that the dataframe did not come from an eager frame. This causes the conversion logic to not attempt to convert the dataframe later in the pipeline. --------- Co-authored-by: Jack Wright <jack.wright@disqo.com>

# Description Work for nushell#7149 - **Error `with-env` given uneven count in list form** - **Fix `with-env` `CantConvert` to record** - **Error `with-env` when given protected env vars** - **Deprecate list/table input of vars to `with-env`** - **Remove examples for deprecated input** # User-Facing Changes ## Deprecation of the following forms ``` > with-env [MYENV "my env value"] { $env.MYENV } my env value > with-env [X Y W Z] { $env.X } Y > with-env [[X W]; [Y Z]] { $env.W } Z ``` ## recommended standardized form ``` # Set by key-value record > with-env {X: "Y", W: "Z"} { [$env.X $env.W] } ╭───┬───╮ │ 0 │ Y │ │ 1 │ Z │ ╰───┴───╯ ``` ## (Side effect) Repeated definitions in an env shorthand are now disallowed ``` > FOO=bar FOO=baz $env Error: nu::shell::column_defined_twice × Record field or table column used twice: FOO ╭─[entry #1:1:1] 1 │ FOO=bar FOO=baz $env · ─┬─ ─┬─ · │ ╰── field redefined here · ╰── field first defined here ╰──── ```

@maxim-uvarov

# Description @maxim-uvarov brought up another case where converting back and forth between eager and lazy dataframes was not working correctly: ``` > [[a b]; [6 2] [1 4] [4 1]] | polars into-lazy | polars append -c ([[a b]; [6 2] [1 4] [4 1]] | polars into-df) Error: nu::shell::cant_convert × Can't convert to NuDataFrame. ╭─[entry #1:1:49] 1 │ [[a b]; [6 2] [1 4] [4 1]] | polars into-lazy | polars append -c ([[a b]; [6 2] [1 4] [4 1]] | polars into-df) · ──────┬────── · ╰── can't convert NuLazyFrameCustomValue to NuDataFrame ╰──── ``` This pull request fixes this case and glaringly obvious similar cases I could find. Co-authored-by: Jack Wright <jack.wright@disqo.com>

Should close nushell#10833 — though I'd imagine that should have already been closed. # Description Very minor tweak, but it was quite noticeable when using Zellij which relies on OSC 2 to set pane titles. Before the change: ![image](https://github.com/nushell/nushell/assets/6251883/b944bbce-2040-4886-9955-3c5b57d368e9) Note that the default `Pane #1` is still showing for the untouched shell, but running a command like `htop` or `ls` correctly sets the title during / afterwards. After this PR: ![image](https://github.com/nushell/nushell/assets/6251883/dd513cfe-923c-450f-b0f2-c66938b0d6f0) There are now no-longer any unset titles — even if the shell hasn't been touched. **As an aside:** I feel quite strongly that (at least OSC 2) shell integration should be enabled by default, as it is for every other Linux shell I've used, but I'm not sure which issues that caused that the default config refers to? Which terminals are broken by shell integration, and could some of the shell integrations be turned on by default after splitting things into sub-options as suggested in nushell#11301 ? # User-Facing Changes You'll just have shell integrations working from right after the shell has been launched, instead of needing to run something first. # Tests + Formatting Not quite sure how to test this one? Are there any other tests that currently exist for shell integration? I couldn't quite track them down... # After Submitting Let me know if you think this needs any user-facing docs changes!

# Description Close: nushell#12514 # User-Facing Changes `^ls | skip 1` will raise an error ```nushell ❯ ^ls | skip 1 Error: nu::shell::only_supports_this_input_type × Input type not supported. ╭─[entry #1:1:2] 1 │ ^ls | skip 1 · ─┬ ──┬─ · │ ╰── only list, binary or range input data is supported · ╰── input type: raw data ╰──── ``` # Tests + Formatting Sorry I can't add it because of the issue: nushell#12558 # After Submitting Nan

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

@yizhepku

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

…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

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

@amtoine

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

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

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

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

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

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

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

amtoine added 6 commits March 19, 2023 09:25

add a clone of nu-tests to run the standard library tests

6f98972

remove all the other tests to speed up process

c7ab392

catch any test error and throw an error

6b34308

this allows the test runner to stop whenever there is a failing test and throw an `$env.LAST_EXIT_CODE` to `1`.

rewrite the runner in a structured way

977afcb

Revert "introduce a few failing tests"

0b90829

This reverts commit 98ec84a.

amtoine closed this Mar 19, 2023

amtoine deleted the test/stdlib-in-the-ci branch March 19, 2023 09:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Test/stdlib in the ci#1

Test/stdlib in the ci#1
amtoine wants to merge 6 commits intomainfrom
test/stdlib-in-the-ci

amtoine commented Mar 19, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant