Bump softprops/action-gh-release from 0.1.13 to 0.1.15 #1
Conversation
This file contains hidden or 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
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
dependabot
bot
added
dependencies
dependabot
bot
force-pushed
the
dependabot/github_actions/softprops/action-gh-release-0.1.15
branch
from
62f2424 to
fd8b75f
Compare
Bumps [softprops/action-gh-release](https://github.com/softprops/action-gh-release) from 0.1.13 to 0.1.15. - [Release notes](https://github.com/softprops/action-gh-release/releases) - [Changelog](https://github.com/softprops/action-gh-release/blob/master/CHANGELOG.md) - [Commits](softprops/action-gh-release@v0.1.13...v0.1.15) --- updated-dependencies: - dependency-name: softprops/action-gh-release dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
force-pushed
the
dependabot/github_actions/softprops/action-gh-release-0.1.15
branch
from
fd8b75f to
1847d4c
Compare
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
bot
deleted the
dependabot/github_actions/softprops/action-gh-release-0.1.15
branch
hustcer
pushed a commit
that referenced
this pull request
Jun 26, 2023
# 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 #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 <!-- 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 -- crates/nu-std/tests/run.nu` 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. -->
hustcer
pushed a commit
that referenced
this pull request
Jul 17, 2023
# 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
hustcer
pushed a commit
that referenced
this pull request
Aug 5, 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. -->
hustcer
pushed a commit
that referenced
this pull request
Aug 18, 2023
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`  # Tests + Formatting # After Submitting
hustcer
pushed a commit
that referenced
this pull request
Sep 13, 2023
# 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>
hustcer
pushed a commit
that referenced
this pull request
Sep 13, 2023
fixes #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.
hustcer
pushed a commit
that referenced
this pull request
Sep 21, 2023
# Description This PR allows the `values` command to support lazy records. closes nushell/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 <!-- 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. -->
hustcer
pushed a commit
that referenced
this pull request
Sep 27, 2023
related to - nushell/nushell#9973 - nushell/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 👍
hustcer
pushed a commit
that referenced
this pull request
Oct 4, 2023
related to - nushell/nushell#9373 - nushell/nushell#8639 might be able to close nushell/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
hustcer
pushed a commit
that referenced
this pull request
Oct 20, 2023
follow-up to - nushell/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
hustcer
pushed a commit
that referenced
this pull request
Oct 20, 2023
related to - nushell/nushell#10478 # Description this PR is the followup removal to nushell/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
hustcer
pushed a commit
that referenced
this pull request
Oct 20, 2023
related to - nushell/nushell#10520 # Description this PR is a followup to nushell/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
hustcer
pushed a commit
that referenced
this pull request
Oct 25, 2023
# Description Fixes: #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 ╰──── ```
hustcer
pushed a commit
that referenced
this pull request
Nov 8, 2023
# Description `split-by` only works on a `Record`, the error type was updated to match, and now uses a more-specific type. (Two type fixes for the price of one!) The `usage` was updated to say "record" as well # User-Facing Changes * Providing the wrong type to `split-by` now gives an error messages with the correct required input type Previously: ``` ❯ ls | get name | split-by type Error: × unsupported input ╭─[entry #267:1:1] 1 │ ls | get name | split-by type · ─┬─ · ╰── requires a table with one row for splitting ╰──── ``` With this PR: ``` ❯ ls | get name | split-by type Error: nu:🐚:type_mismatch × Type mismatch. ╭─[entry #1:1:1] 1 │ ls | get name | split-by type · ─┬─ · ╰── requires a record to split ╰──── ``` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting Only generated commands need to be updated --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
hustcer
pushed 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
╰────
```
hustcer
pushed a commit
that referenced
this pull request
Dec 4, 2023
# Description This PR adds checks for ports. This fixes unexpected output similar to the one in the comment nushell/nushell#11210 (comment). * before ```console /data/source/nushell> port 65536 99999 41233 ``` * after ```console /data/source/nushell> port 65536 99999 Error: nu::shell::cant_convert × Can't convert to u16. ╭─[entry #1:1:1] 1 │ port 65536 99999 · ──┬── · ╰── can't convert usize to u16 ╰──── help: out of range integral type conversion attempted (min: 0, max: 65535) ``` # User-Facing Changes N/A # Tests + Formatting * [x] add `port_out_of_range` test # After Submitting N/A
hustcer
pushed a commit
that referenced
this pull request
Dec 5, 2023
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 ╰──── ```
hustcer
pushed a commit
that referenced
this pull request
Jan 31, 2024
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> This fixes an issue brought up by nihilander in [Discord](https://discord.com/channels/601130461678272522/614593951969574961/1201594105986285649). # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) 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. --> 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 <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Stuff like `do { ...$rest }` will now try to run a command `...$rest` rather than complaining that variable `$rest` doesn't exist. # 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. --> Sorry about the issue, I am not touching the parser again for a long time :)
hustcer
pushed a commit
that referenced
this pull request
Feb 4, 2024
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) 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. --> Fixes nushell/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 <!-- 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. -->
hustcer
pushed a commit
that referenced
this pull request
Feb 4, 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. -->
hustcer
pushed a commit
that referenced
this pull request
Feb 9, 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.
hustcer
pushed a commit
that referenced
this pull request
Feb 18, 2024
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description Fix #11732 <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) 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. --> 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 <!-- 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. -->
hustcer
pushed a commit
that referenced
this pull request
Apr 7, 2024
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description Resolves #11756. Resolves #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 ╰──── ``` <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) 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` 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 > ``` --> Added relevant test 🚀 # 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. --> Possibly support `get` `get`ting negative numbers, as per #12346 discussion. Alternatively, we can consider adding a cellpath for negative indexing?
hustcer
pushed a commit
that referenced
this pull request
Apr 14, 2024
# 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>
hustcer
pushed a commit
that referenced
this pull request
Apr 16, 2024
# Description
Fixes #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.
hustcer
pushed a commit
that referenced
this pull request
Apr 16, 2024
…to eager frames later in the pipeline. (#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>
hustcer
pushed a commit
that referenced
this pull request
Apr 17, 2024
# Description
Work for #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
╰────
```
hustcer
pushed a commit
that referenced
this pull request
Apr 17, 2024
# 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>
hustcer
pushed a commit
that referenced
this pull request
Apr 20, 2024
Should close #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:  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:  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 #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!
hustcer
pushed a commit
that referenced
this pull request
Apr 20, 2024
# Description Close: #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/nushell#12558 # After Submitting Nan
hustcer
pushed a commit
that referenced
this pull request
May 2, 2024
…stStream` (#12412) <!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) 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. --> Prior, it seemed that nested errors would not get detected and shown. This PR fixes that. Resolves #10176: ``` ~/CodingProjects/nushell> [[1,2]] | each {|x| $x | each {|y| error make {msg: "oh noes"} } } 05/04/2024 21:34:08 Error: nu::shell::eval_block_with_input × Eval block failed with pipeline input ╭─[entry #1:1:3] 1 │ [[1,2]] | each {|x| $x | each {|y| error make {msg: "oh noes"} } } · ┬ · ╰── source value ╰──── Error: × oh noes ╭─[entry #1:1:36] 1 │ [[1,2]] | each {|x| $x | each {|y| error make {msg: "oh noes"} } } · ─────┬──── · ╰── originates from here ╰──── ``` Resolves #11224: ``` ~/CodingProjects/nushell> [0] | each { |_| 05/04/2024 21:35:40 ::: [0] | each { |_| ::: non-existent-command ::: } ::: } Error: nu::shell::eval_block_with_input × Eval block failed with pipeline input ╭─[entry #1:2:6] 1 │ [0] | each { |_| 2 │ [0] | each { |_| · ┬ · ╰── source value 3 │ non-existent-command ╰──── Error: nu:🐚:external_command × External command failed ╭─[entry #1:3:9] 2 │ [0] | each { |_| 3 │ non-existent-command · ──────────┬───────── · ╰── executable was not found 4 │ } ╰──── help: No such file or directory (os error 2) ``` # User-Facing Changes <!-- 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. -->
hustcer
pushed a commit
that referenced
this pull request
May 31, 2024
# Description Fix a regression introduced by #12921, where tilde expansion was no longer done on the external command name, breaking things like ```nushell > ~/.cargo/bin/exa ``` This properly handles quoted strings, so they don't expand: ```nushell > ^"~/.cargo/bin/exa" Error: nu::shell::external_command × External command failed ╭─[entry #1:1:2] 1 │ ^"~/.cargo/bin/exa" · ─────────┬──────── · ╰── Command `~/.cargo/bin/exa` not found ╰──── help: `~/.cargo/bin/exa` is neither a Nushell built-in or a known external command ``` This required a change to the parser, so the command name is also parsed in the same way the arguments are - i.e. the quotes on the outside remain in the expression. Hopefully that doesn't break anything else. 🤞 Fixes #13000. Should include in patch release 0.94.1 cc @yizhepku # User-Facing Changes - Tilde expansion now works again for external commands - The `command` of `run-external` will now have its quotes removed like the other arguments if it is a literal string - The parser is changed to include quotes in the command expression of `ExternalCall` if they were present # Tests + Formatting I would like to add a regression test for this, but it's complicated because we need a well-known binary within the home directory, which just isn't a thing. We could drop one there, but that's kind of a bad behavior for a test to do. I also considered changing the home directory for the test, but that's so platform-specific - potentially could get it working on specific platforms though. Changing `HOME` env on Linux definitely works as far as tilde expansion works. - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib`
hustcer
pushed a commit
that referenced
this pull request
Jun 28, 2024
…#13131) # Description Closes: #13010 It adds an additional check inside `parse_string`, and returns `unbalanced quote` if input string is unbalanced # User-Facing Changes After this pr, the following is no longer allowed: ```nushell ❯ "asdfasdf"asdfasdf Error: nu::parser::extra_token_after_closing_delimiter × Invaild characters after closing delimiter ╭─[entry #1:1:11] 1 │ "asdfasdf"asdfasdf · ────┬─── · ╰── invalid characters ╰──── help: Try removing them. ❯ 'asdfasd'adsfadf Error: nu::parser::extra_token_after_closing_delimiter × Invaild characters after closing delimiter ╭─[entry #2:1:10] 1 │ 'asdfasd'adsfadf · ───┬─── · ╰── invalid characters ╰──── help: Try removing them. ``` # Tests + Formatting Added 1 test
hustcer
pushed a commit
that referenced
this pull request
Jul 5, 2024
# Description Fixes #13280. After apply this patch, we can use non-timezone string + format option `into datetime` cmd # User-Facing Changes AS-IS (before fixing) ``` $ "09.02.2024 11:06:11" | into datetime --format '%m.%d.%Y %T' Error: nu::shell::cant_convert × Can't convert to could not parse as datetime using format '%m.%d.%Y %T'. ╭─[entry #1:1:25] 1 │ "09.02.2024 11:06:11" | into datetime --format '%m.%d.%Y %T' · ──────┬────── · ╰── can't convert input is not enough for unique date and time to could not parse as datetime using format '%m.%d.%Y %T' ╰──── help: you can use `into datetime` without a format string to enable flexible parsing $ "09.02.2024 11:06:11" | into datetime Mon, 2 Sep 2024 11:06:11 +0900 (in 2 months) ``` TO-BE(After fixing) ``` $ "09.02.2024 11:06:11" | into datetime --format '%m.%d.%Y %T' Mon, 2 Sep 2024 20:06:11 +0900 (in 2 months) $ "09.02.2024 11:06:11" | into datetime Mon, 2 Sep 2024 11:06:11 +0900 (in 2 months) ``` # Tests + Formatting If there is agreement on the direction, I will add a test. # After Submitting --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
hustcer
pushed a commit
that referenced
this pull request
Jul 10, 2024
# 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>
hustcer
pushed a commit
that referenced
this pull request
Aug 14, 2024
# Description As part of fixing nushell/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:  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.
hustcer
pushed a commit
that referenced
this pull request
Sep 7, 2024
# Description
This PR makes it so that non-zero exit codes and termination by signal
are treated as a normal `ShellError`. Currently, these are silent
errors. That is, if an external command fails, then it's code block is
aborted, but the parent block can sometimes continue execution. E.g.,
see #8569 and this example:
```nushell
[1 2] | each { ^false }
```
Before this would give:
```
╭───┬──╮
│ 0 │ │
│ 1 │ │
╰───┴──╯
```
Now, this shows an error:
```
Error: nu::shell::eval_block_with_input
× Eval block failed with pipeline input
╭─[entry #1:1:2]
1 │ [1 2] | each { ^false }
· ┬
· ╰── source value
╰────
Error: nu:🐚:non_zero_exit_code
× External command had a non-zero exit code
╭─[entry #1:1:17]
1 │ [1 2] | each { ^false }
· ──┬──
· ╰── exited with code 1
╰────
```
This PR fixes #12874, fixes #5960, fixes #10856, and fixes #5347. This
PR also partially addresses #10633 and #10624 (only the last command of
a pipeline is currently checked). It looks like #8569 is already fixed,
but this PR will make sure it is definitely fixed (fixes #8569).
# User-Facing Changes
- Non-zero exit codes and termination by signal now cause an error to be
thrown.
- The error record value passed to a `catch` block may now have an
`exit_code` column containing the integer exit code if the error was due
to an external command.
- Adds new config values, `display_errors.exit_code` and
`display_errors.termination_signal`, which determine whether an error
message should be printed in the respective error cases. For
non-interactive sessions, these are set to `true`, and for interactive
sessions `display_errors.exit_code` is false (via the default config).
# Tests
Added a few tests.
# After Submitting
- Update docs and book.
- Future work:
- Error if other external commands besides the last in a pipeline exit
with a non-zero exit code. Then, deprecate `do -c` since this will be
the default behavior everywhere.
- Add a better mechanism for exit codes and deprecate
`$env.LAST_EXIT_CODE` (it's buggy).
hustcer
pushed a commit
that referenced
this pull request
Sep 28, 2024
# Description Old code was comparing remaining positional arguments with total number of arguments, where it should've compared remaining positional with with remaining arguments of any kind. This means that if a function was given too few arguments, `calculate_end_span` would believe that it actually had too many arguments, since after parsing the first few arguments, the number of remaining arguments needed were fewer than the *total* number of arguments, of which we had used several. Fixes #9072 Fixes: nushell/nushell#13930 Fixes: nushell/nushell#12069 Fixes: nushell/nushell#8385 Extracted from #10381 ## Bonus It also improves the error handling on missing positional arguments before keywords (no longer crashing since #9851). Instead of just giving the keyword to the parser for the missing positional, we give an explicit error about a missing positional argument. I would like better descriptions than "missing var_name" though, but I'm not sure if that's available without Old error ``` Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #1:1:1] 1 │ let = if foo · ┬ · ╰── expected valid variable name ╰──── ``` New error ``` Error: nu::parser::missing_positional × Missing required positional argument. ╭─[entry #18:1:1] 1 │ let = foo · ┬ · ╰── missing var_name ╰──── help: Usage: let <var_name> = <initial_value> ``` # User-Facing Changes The program `alias = = =` is no longer accepted by the parser
hustcer
pushed a commit
that referenced
this pull request
Oct 18, 2024
# 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 <!-- 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 toolkit.nu; toolkit test stdlib"` 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. -->
hustcer
pushed a commit
that referenced
this pull request
Oct 21, 2024
# 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 <!-- 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 toolkit.nu; toolkit test stdlib"` 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. -->
hustcer
pushed a commit
that referenced
this pull request
Oct 23, 2024
Fixes #14023
# Description
- Prevents "failed to find added variable" when modules export constants
with type signatures:
```nushell
> module foo { export const bar: int = 2 }
Error: nu::parser::unknown_state
× Internal error.
╭─[entry #1:1:21]
1 │ module foo { export const bar: int = 2 }
· ─────────┬────────
· ╰── failed to find added variable
```
- Returns `name_is_builtin_var` errors for names with type signatures:
```nushell
> let env: string = "";
Error: nu::parser::name_is_builtin_var
× `env` used as variable name.
╭─[entry #1:1:5]
1 │ let env: string = "";
· ─┬─
· ╰── already a builtin variable
```
hustcer
pushed a commit
that referenced
this pull request
Oct 30, 2024
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) 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. --> 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 <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> `to nuon` now properly escapes quotes in column names. # 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 toolkit.nu; toolkit test stdlib"` 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 > ``` --> All tests pass, including workspace and stdlib tests. # 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. -->
hustcer
pushed a commit
that referenced
this pull request
Dec 6, 2024
… (#14353)
Fixes #14252
# User-Facing Changes
- Special characters in module names are replaced with underscores when
importing constants, preventing "expected valid variable name":
```nushell
> module foo-bar { export const baz = 1 }
> use foo-bar
> $foo_bar.baz
```
- "expected valid variable name" errors now include a suggestion list:
```nushell
> module foo-bar { export const baz = 1 }
> use foo-bar
> $foo-bar
Error: nu::parser::parse_mismatch_with_did_you_mean
× Parse mismatch during operation.
╭─[entry #1:1:1]
1 │ $foo-bar;
· ────┬───
· ╰── expected valid variable name. Did you mean '$foo_bar'?
╰────
```
hustcer
pushed a commit
that referenced
this pull request
Dec 7, 2024
…time (#14303)
Alternative solution to:
- #12195
The other approach:
- #14305
# Description
Adds ~`path const`~ `path self`, a parse-time only command for getting
the absolute path of the source file containing it, or any file relative
to the source file.
- Useful for any script or module that makes use of non nuscript files.
- Removes the need for `$env.CURRENT_FILE` and `$env.FILE_PWD`.
- Can be used in modules, sourced files or scripts.
# Examples
```nushell
# ~/.config/nushell/scripts/foo.nu
const paths = {
self: (path self),
dir: (path self .),
sibling: (path self sibling),
parent_dir: (path self ..),
cousin: (path self ../cousin),
}
export def main [] {
$paths
}
```
```nushell
> use foo.nu
> foo
╭────────────┬────────────────────────────────────────────╮
│ self │ /home/user/.config/nushell/scripts/foo.nu │
│ dir │ /home/user/.config/nushell/scripts │
│ sibling │ /home/user/.config/nushell/scripts/sibling │
│ parent_dir │ /home/user/.config/nushell │
│ cousin │ /home/user/.config/nushell/cousin │
╰────────────┴────────────────────────────────────────────╯
```
Trying to run in a non-const context
```nushell
> path self
Error: × this command can only run during parse-time
╭─[entry #1:1:1]
1 │ path self
· ─────┬────
· ╰── can't run after parse-time
╰────
help: try assigning this command's output to a const variable
```
Trying to run in the REPL i.e. not in a file
```nushell
> const foo = path self
Error: × Error: nu:🐚:file_not_found
│
│ × File not found
│ ╭─[entry #3:1:13]
│ 1 │ const foo = path self
│ · ─────┬────
│ · ╰── Couldn't find current file
│ ╰────
│
╭─[entry #3:1:13]
1 │ const foo = path self
· ─────┬────
· ╰── Encountered error during parse-time evaluation
╰────
```
# Comparison with #14305
## Pros
- Self contained implementation, does not require changes in the parser.
- More concise usage, especially with parent directories.
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
hustcer
pushed a commit
that referenced
this pull request
Dec 14, 2024
# Description Closes #14521 This PR tweaks the way 64-bit hex numbers are parsed. ### Before ```nushell ❯ 0xffffffffffffffef Error: nu::shell::external_command × External command failed ╭─[entry #1:1:1] 1 │ 0xffffffffffffffef · ─────────┬──────── · ╰── Command `0xffffffffffffffef` not found ╰──── help: `0xffffffffffffffef` is neither a Nushell built-in or a known external command ``` ### After ```nushell ❯ 0xffffffffffffffef -17 ``` # 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 toolkit.nu; toolkit test stdlib"` 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. -->
hustcer
pushed a commit
that referenced
this pull request
Feb 3, 2025
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) 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. --> This PR makes two changes related to [run-time pipeline input type checking](nushell/nushell#14741): 1. The check which bypasses type checking for commands with only `Type::Nothing` input types has been expanded to work with commands with multiple `Type::Nothing` inputs for different outputs. For example, `ast` has three input/output type pairs, but all of the inputs are `Type::Nothing`: ``` ╭───┬─────────┬────────╮ │ # │ input │ output │ ├───┼─────────┼────────┤ │ 0 │ nothing │ table │ │ 1 │ nothing │ record │ │ 2 │ nothing │ string │ ╰───┴─────────┴────────╯ ``` Before this PR, passing a value (which would otherwise be ignored) to `ast` caused a run-time type error: ``` Error: nu::shell::only_supports_this_input_type × Input type not supported. ╭─[entry #1:1:6] 1 │ echo 123 | ast -j -f "hi" · ─┬─ ─┬─ · │ ╰── only nothing, nothing, and nothing input data is supported · ╰── input type: int ╰──── ``` After this PR, no error is raised. This doesn't really matter for `ast` (the only other built-in command with a similar input/output type signature is `cal`), but it's more logically consistent. 2. Bypasses input type-checking (parse-time ***and*** run-time) for some (not all, see below) commands which have both a `Type::Nothing` input and some other non-nothing `Type` input. This is accomplished by adding a `Type::Any` input with the same output as the corresponding `Type::Nothing` input/output pair. This is necessary because some commands are intended to operate on an argument with empty pipeline input, or operate on an empty pipeline input with no argument. This causes issues when a value is implicitly passed to one of these commands. I [discovered this issue](https://discord.com/channels/601130461678272522/615962413203718156/1329945784346611712) when working with an example where the `open` command is used in `sort-by` closure: ```nushell ls | sort-by { open -r $in.name | lines | length } ``` Before this PR (but after the run-time input type checking PR), this error is raised: ``` Error: nu::shell::only_supports_this_input_type × Input type not supported. ╭─[entry #1:1:1] 1 │ ls | sort-by { open -r $in.name | lines | length } · ─┬ ──┬─ · │ ╰── only nothing and string input data is supported · ╰── input type: record<name: string, type: string, size: filesize, modified: date> ╰──── ``` While this error is technically correct, we don't actually want to return an error here since `open` ignores its pipeline input when an argument is passed. This would be a parse-time error as well if the parser was able to infer that the closure input type was a record, but our type inference isn't that robust currently, so this technically incorrect form snuck by type checking until #14741. However, there are some commands with the same kind of type signature where this behavior is actually desirable. This means we can't just bypass type-checking for any command with a `Type::Nothing` input. These commands operate on true `null` values, rather than ignoring their input. For example, `length` returns `0` when passed a `null` value. It's correct, and even desirable, to throw a run-time error when `length` is passed an unexpected type. For example, a string, which should instead be measured with `str length`: ```nushell ["hello" "world"] | sort-by { length } # => Error: nu::shell::only_supports_this_input_type # => # => × Input type not supported. # => ╭─[entry #32:1:10] # => 1 │ ["hello" "world"] | sort-by { length } # => · ───┬─── ───┬── # => · │ ╰── only list<any>, binary, and nothing input data is supported # => · ╰── input type: string # => ╰──── ``` We need a more robust way for commands to express how they handle the `Type::Nothing` input case. I think a possible solution here is to allow commands to express that they operate on `PipelineData::Empty`, rather than `Value::Nothing`. Then, a command like `open` could have an empty pipeline input type rather than a `Type::Nothing`, and the parse-time and run-time pipeline input type checks know that `open` will safely ignore an incorrectly typed input. That being said, we have a release coming up and the above solution might take a while to implement, so while unfortunate, bypassing input type-checking for these problematic commands serves as a workaround to avoid breaking changes in the release until a more robust solution is implemented. This PR bypasses input type-checking for the following commands: * `load-env`: can take record of envvars as input or argument * `nu-check`: checks input string or filename argument * `open`: can take filename as input or argument * `polars when`: can be used with input, or can be chained with another `polars when` * `stor insert`: data record can be passed as input or argument * `stor update`: data record can be passed as input or argument * `format date`: `--list` ignores input value * `into datetime`: `--list` ignores input value (also added a `Type::Nothing` input which was missing from this command) These commands have a similar input/output signature to the above commands, but are working as intended: * `cd`: The input/output signature was actually incorrect, `cd` always ignores its input. I fixed this in this PR. * `generate` * `get` * `history import` * `interleave` * `into bool` * `length` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> As a temporary workaround, pipeline input type-checking for the following commands has been bypassed to avoid undesirable run-time input type checking errors which were previously not caught at parse-time: * `open` * `load-env` * `format date` * `into datetime` * `nu-check` * `stor insert` * `stor update` * `polars when` # 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 toolkit.nu; toolkit test stdlib"` 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 > ``` --> CI became green in the time it took me to type the description 😄 # 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. --> N/A
hustcer
pushed a commit
that referenced
this pull request
Feb 8, 2025
Fixes #14960 # User-Facing Changes - The output of non-streaming values can now be interrupted with ctrl-c: ```nushell ~> use std repeat; random chars --length 100kb | repeat 2000 | str join ' ' | collect <data omitted>^C Error: × Operation interrupted ╭─[entry #1:1:61] 1 │ use std repeat; random chars --length 100kb | repeat 2000 | str join ' ' | collect · ────┬─── · ╰── This operation was interrupted ╰──── ``` - When IO errors occur while printing data, nushell no longer panics: ```diff $ nu -c "true | print" | - -Error: - x Main thread panicked. - |-> at crates/nu-protocol/src/errors/shell_error/io.rs:198:13 - `-> for unknown spans with paths, use `new_internal_with_path` +Error: nu:🐚:io::broken_pipe + + x I/O error + `-> x Broken pipe + + ,-[source:1:1] + 1 | true | print + : ^^|^ + : `-| Writing to stdout failed + : | Broken pipe + `---- ```
hustcer
pushed a commit
that referenced
this pull request
Feb 14, 2025
# Description This PR adds two new `ParseError` and `ShellError` cases for type errors relating to operators. - `OperatorUnsupportedType` is used when a type is not supported by an operator in any way, shape, or form. E.g., `+` does not support `bool`. - `OperatorIncompatibleTypes` is used when a operator is used with types it supports, but the combination of types provided cannot be used together. E.g., `filesize + duration` is not a valid combination. The other preexisting error cases related to operators have been removed and replaced with the new ones above. Namely: - `ShellError::OperatorMismatch` - `ShellError::UnsupportedOperator` - `ParseError::UnsupportedOperationLHS` - `ParseError::UnsupportedOperationRHS` - `ParseError::UnsupportedOperationTernary` # User-Facing Changes - `help operators` now lists the precedence of `not` as 55 instead of 0 (above the other boolean operators). Fixes #13675. - `math median` and `math mode` now ignore NaN values so that `[NaN NaN] | math median` and `[NaN NaN] | math mode` no longer trigger a type error. Instead, it's now an empty input error. Fixing this in earnest can be left for a future PR. - Comparisons with `nan` now return false instead of causing an error. E.g., `1 == nan` is now `false`. - All the operator type errors have been standardized and reworked. In particular, they can now have a help message, which is currently used for types errors relating to `++`. ```nu [1] ++ 2 ``` ``` Error: nu::parser::operator_unsupported_type × The '++' operator does not work on values of type 'int'. ╭─[entry #1:1:5] 1 │ [1] ++ 2 · ─┬ ┬ · │ ╰── int · ╰── does not support 'int' ╰──── help: if you meant to append a value to a list or a record to a table, use the `append` command or wrap the value in a list. For example: `$list ++ $value` should be `$list ++ [$value]` or `$list | append $value`. ```
hustcer
pushed a commit
that referenced
this pull request
Mar 21, 2025
Closes #15160
# User-Facing Changes
Certain "variable not found" errors no longer highlight the surrounding
block.
Before:
```nushell
do {
match foo {
_ => $in
}
}
Error: nu::shell::variable_not_found
× Variable not found
╭─[entry #1:1:1]
1 │ ╭─▶ do {
2 │ │ match foo {
3 │ │ _ => $in
4 │ │ }
5 │ ├─▶ }
· ╰──── variable not found
```
After:
```nushell
Error: nu:🐚:variable_not_found
× Variable not found
╭─[entry #1:3:10]
2 │ match foo {
3 │ _ => $in
· ─┬─
· ╰── variable not found
```
hustcer
pushed a commit
that referenced
this pull request
Jun 13, 2025
# Description When attempting to pass a null byte in a commandline argument, Nu currently fails with: ``` > ^echo (char -i 0) Error: nu::shell::io::invalid_input × I/O error ╰─▶ × Could not spawn foreground child ╭──── 1 │ crates/nu-command/src/system/run_external.rs:284:17 · ─────────────────────────┬───────────────────────── · ╰── Invalid input parameter ╰──── ``` This does not explain which input parameter is invalid, or why. Since Nu does not typically seem to escape null bytes when printing values containing them, this can make it a bit tricky to track down the problem. After this change, it fails with: ``` > ^echo (char -i 0) Error: nu::shell::io::invalid_input × I/O error ╰─▶ × Could not spawn foreground child: nul byte found in provided data ╭──── 1 │ crates/nu-command/src/system/run_external.rs:282:17 · ─────────────────────────┬───────────────────────── · ╰── Invalid input parameter ╰──── ``` which is more useful. This could be improved further but this is niche enough that is probably not necessary. This might make some other errors unnecessarily verbose but seems like the better default. I did check that attempting to execute a non-executable file still has a reasonable error: the error message for that failure is not affected by this change. It is still an "internal" error (referencing the Nu code triggering it, not the user's input) because the `call.head` span available to this code is for the command, not its arguments. Using it would result in ``` × I/O error ╰─▶ × Could not spawn foreground child: nul byte found in provided data ╭─[entry #1:1:2] 1 │ ^echo (char -i 0) · ──┬─ · ╰── Invalid input parameter ╰──── ``` which is actively misleading because "echo" does not contain the nul byte. # 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 toolkit.nu; toolkit test stdlib"` 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 > ``` --> Haven't tried to write a test yet: it's tricky because the better error message comes from the Rust stdlib (so a straightforward integration test checking for the specific message would be brittle)... # 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. -->
hustcer
pushed a commit
that referenced
this pull request
Jul 5, 2025
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) 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. --> Rel: #14429, #16079 Finishes up a TODO in the assignment type checking. - For regular assignment operations (only applies to `mut`), type checking is now done using `type_compatible` (which is what `let` uses) - This allows some mutable assignments to work which weren't allowed before Before: ```nushell let x: glob = "" # => ok, no error mut x: glob = ""; $x = "" # => Error: nu::parser::operator_incompatible_types # => # => × Types 'glob' and 'string' are not compatible for the '=' operator. # => ╭─[entry #6:1:19] # => 1 │ mut x: glob = ""; $x = "" # => · ─┬ ┬ ─┬ # => · │ │ ╰── string # => · │ ╰── does not operate between 'glob' and 'string' # => · ╰── glob # => ╰──── let x: number = 1 # ok, no error mut x: number = 1; $x = 2 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'number' and 'int' are not compatible for the '=' operator. # => ╭─[source:1:20] # => 1 │ mut x: number = 1; $x = 2 # => · ─┬ ┬ ┬ # => · │ │ ╰── int # => · │ ╰── does not operate between 'number' and 'int' # => · ╰── number # => ╰──── ``` After: ```nushell let x: glob = "" # ok, no error (same as before) mut x: glob = ""; $x = "" # ok, no error let x: number = 1 # ok, no error (same as before) mut x: number = 1; $x = 2 # ok, no error ``` - Properly type check compound operations. First checks if the operation (eg. `+` for `+=`) type checks successfully, and then checks if the assignment type checks successfully (also using `type_compatible`) - This fixes some issues where the "long version" of a compound assignment operator would error, but the compound assignment operator itself would not Before: ```nushell mut x = 1; $x = $x / 2 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'int' and 'float' are not compatible for the '=' operator. # => ╭─[entry #15:1:12] # => 1 │ mut x = 1; $x = $x / 2 # => · ─┬ ┬ ───┬── # => · │ │ ╰── float # => · │ ╰── does not operate between 'int' and 'float' # => · ╰── int # => ╰──── mut x = 1; $x /= 2 # uh oh, no error... mut x = (date now); $x = $x - 2019-05-10 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'datetime' and 'duration' are not compatible for the '=' operator. # => ╭─[entry #1:1:21] # => 1 │ mut x = (date now); $x = $x - 2019-05-10 # => · ─┬ ┬ ───────┬─────── # => · │ │ ╰── duration # => · │ ╰── does not operate between 'datetime' and 'duration' # => · ╰── datetime # => ╰──── mut x = (date now); $x -= 2019-05-10 # uh oh, no error... (the result of this is a duration, not a datetime) ``` After: ```nushell mut x = 1; $x = $x / 2 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'int' and 'float' are not compatible for the '=' operator. # => ╭─[entry #5:1:12] # => 1 │ mut x = 1; $x = $x / 2 # => · ─┬ ┬ ───┬── # => · │ │ ╰── float # => · │ ╰── does not operate between 'int' and 'float' # => · ╰── int # => ╰──── mut x = (date now); $x -= 2019-05-10 # => Error: nu::parser::operator_incompatible_types # => # => × Types 'datetime' and 'datetime' are not compatible for the '-=' operator. # => ╭─[entry #11:1:21] # => 1 │ mut x = (date now); $x -= 2019-05-10 # => · ─┬ ─┬ ─────┬──── # => · │ │ ╰── datetime # => · │ ╰── does not operate between 'datetime' and 'datetime' # => · ╰── datetime # => ╰──── # => help: The result type of this operation is not compatible with the type of the variable. ``` This is technically a breaking change if you relied on the old behavior (for example, there was a test that broke after this change because it relied on `/=` improperly type checking) # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> * Mutable assignment operations now use the same type checking rules as normal assignments * For example, `$x = 123` now uses the same type checking rules as `let x = 123` or `mut x = 123` * Compound assignment operations now type check using the same rules as the operation they use * Assignment errors will also now highlight the invalid assignment operator in red # 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 toolkit.nu; toolkit test stdlib"` 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 > ``` --> Adds some tests for the examples given above # 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. --> N/A
hustcer
pushed a commit
that referenced
this pull request
Jul 16, 2025
# Description
Before this PR, errors without error codes are printed somewhat
strangely, with the `×` and the description being printed on the same
line as the `Error:` text:
Error: × Invalid literal
╭─[entry #1:1:2]
1 │ "\z"
· ─┬─
· ╰── unrecognized escape after '\' in string
╰────
This PR adds a default error code for the different error types:
Error: nu::parser::error
× Invalid literal
╭─[entry #1:1:2]
1 │ "\z"
· ─┬─
· ╰── unrecognized escape after '\' in string
╰────
While maybe not as informative as a proper error code, it makes
`GenericError`s and other things which don't have error codes look a lot
nicer.
It would be nicer if we could just set `diagnostic(code:
"nu:🐚:error")` at the top of `ShellError`, but unfortunately you
can't set a "default" at the `enum` level and then override it in the
variants. @cptpiepmatz mentioned he might change miette's derive macro
to accommodate this, in that case we can switch the approach here.
# User-Facing Changes
* Errors without error codes now have a default error code corresponding
to from which part of Nushell the error occurred (shell, parser,
compile, etc)
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
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.
Bumps softprops/action-gh-release from 0.1.13 to 0.1.15.
Release notes
Sourced from softprops/action-gh-release's releases.
Changelog
Sourced from softprops/action-gh-release's changelog.
Commits
de2c0ebupdate changelogc4dd327add nvmrc0bd7e8bUpdate all dependencies + dependabot.yml configuration + node16 (#275)cd28b0fFix typo in description (#212)faf0426Fixes wrong outdated URL (#242)50195baUpdate README.md (#234)fe9a9bdadd append_body option (#199)8a65c81document target_commitish default (#190)44946dcrebuild58fa4b7Addassetsaction output (#185)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)