2021-09-20 21:37:26 +00:00
use miette ::Diagnostic ;
2021-10-01 05:11:49 +00:00
use serde ::{ Deserialize , Serialize } ;
Replace `ExternalStream` with new `ByteStream` type (#12774)
# Description
This PR introduces a `ByteStream` type which is a `Read`-able stream of
bytes. Internally, it has an enum over three different byte stream
sources:
```rust
pub enum ByteStreamSource {
Read(Box<dyn Read + Send + 'static>),
File(File),
Child(ChildProcess),
}
```
This is in comparison to the current `RawStream` type, which is an
`Iterator<Item = Vec<u8>>` and has to allocate for each read chunk.
Currently, `PipelineData::ExternalStream` serves a weird dual role where
it is either external command output or a wrapper around `RawStream`.
`ByteStream` makes this distinction more clear (via `ByteStreamSource`)
and replaces `PipelineData::ExternalStream` in this PR:
```rust
pub enum PipelineData {
Empty,
Value(Value, Option<PipelineMetadata>),
ListStream(ListStream, Option<PipelineMetadata>),
ByteStream(ByteStream, Option<PipelineMetadata>),
}
```
The PR is relatively large, but a decent amount of it is just repetitive
changes.
This PR fixes #7017, fixes #10763, and fixes #12369.
This PR also improves performance when piping external commands. Nushell
should, in most cases, have competitive pipeline throughput compared to,
e.g., bash.
| Command | Before (MB/s) | After (MB/s) | Bash (MB/s) |
| -------------------------------------------------- | -------------:|
------------:| -----------:|
| `throughput \| rg 'x'` | 3059 | 3744 | 3739 |
| `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 |
# User-Facing Changes
- This is a breaking change for the plugin communication protocol,
because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`.
Plugins now only have to deal with a single input stream, as opposed to
the previous three streams: stdout, stderr, and exit code.
- The output of `describe` has been changed for external/byte streams.
- Temporary breaking change: `bytes starts-with` no longer works with
byte streams. This is to keep the PR smaller, and `bytes ends-with`
already does not work on byte streams.
- If a process core dumped, then instead of having a `Value::Error` in
the `exit_code` column of the output returned from `complete`, it now is
a `Value::Int` with the negation of the signal number.
# After Submitting
- Update docs and book as necessary
- Release notes (e.g., plugin protocol changes)
- Adapt/convert commands to work with byte streams (high priority is
`str length`, `bytes starts-with`, and maybe `bytes ends-with`).
- Refactor the `tee` code, Devyn has already done some work on this.
---------
Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 14:11:18 +00:00
use std ::io ;
2021-09-20 21:37:26 +00:00
use thiserror ::Error ;
2024-03-02 17:14:02 +00:00
use crate ::{
2024-03-30 13:21:40 +00:00
ast ::Operator , engine ::StateWorkingSet , format_error , LabeledError , ParseError , Span , Spanned ,
Value ,
2024-03-02 17:14:02 +00:00
} ;
2021-09-02 01:29:43 +00:00
2021-11-03 00:26:09 +00:00
/// The fundamental error type for the evaluation engine. These cases represent different kinds of errors
/// the evaluator might face, along with helpful spans to label. An error renderer will take this error value
/// and pass it into an error viewer to display to the user.
2024-03-30 13:21:40 +00:00
#[ derive(Debug, Clone, Error, Diagnostic, PartialEq) ]
2021-09-02 01:29:43 +00:00
pub enum ShellError {
2022-04-14 05:08:46 +00:00
/// An operator received two arguments of incompatible types.
///
/// ## Resolution
///
/// Check each argument's type and convert one or both as needed.
2021-09-20 21:37:26 +00:00
#[ error( " Type mismatch during operation. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::type_mismatch)) ]
2021-09-02 01:29:43 +00:00
OperatorMismatch {
2021-09-20 21:37:26 +00:00
#[ label = " type mismatch for operator " ]
2021-09-02 01:29:43 +00:00
op_span : Span ,
2023-05-24 22:58:18 +00:00
lhs_ty : String ,
2021-09-20 21:37:26 +00:00
#[ label( " {lhs_ty} " ) ]
2021-09-02 01:29:43 +00:00
lhs_span : Span ,
2023-05-24 22:58:18 +00:00
rhs_ty : String ,
2021-09-20 21:37:26 +00:00
#[ label( " {rhs_ty} " ) ]
2021-09-02 01:29:43 +00:00
rhs_span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2022-04-14 05:08:46 +00:00
/// An arithmetic operation's resulting value overflowed its possible size.
///
/// ## Resolution
///
/// Check the inputs to the operation and add guards for their sizes.
/// Integers are generally of size i64, floats are generally f64.
2021-10-20 05:58:25 +00:00
#[ error( " Operator overflow. " ) ]
2023-03-01 19:34:48 +00:00
#[ diagnostic(code(nu::shell::operator_overflow), help( " {help} " )) ]
OperatorOverflow {
msg : String ,
#[ label = " {msg} " ]
span : Span ,
help : String ,
} ,
2021-10-20 05:58:25 +00:00
2022-04-14 05:08:46 +00:00
/// The pipelined input into a command was not of the expected type. For example, it might
/// expect a string input, but received a table instead.
///
/// ## Resolution
///
/// Check the relevant pipeline and extract or convert values as needed.
2021-10-09 01:02:01 +00:00
#[ error( " Pipeline mismatch. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::pipeline_mismatch)) ]
2023-03-01 19:34:48 +00:00
PipelineMismatch {
exp_input_type : String ,
#[ label( " expected: {exp_input_type} " ) ]
dst_span : Span ,
#[ label( " value originates from here " ) ]
src_span : Span ,
} ,
2021-12-02 23:11:25 +00:00
2023-03-01 19:34:48 +00:00
// TODO: properly unify
/// The pipelined input into a command was not of the expected type. For example, it might
/// expect a string input, but received a table instead.
///
/// (duplicate of [`ShellError::PipelineMismatch`] that reports the observed type)
///
/// ## Resolution
///
/// Check the relevant pipeline and extract or convert values as needed.
2023-01-01 05:56:59 +00:00
#[ error( " Input type not supported. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::only_supports_this_input_type)) ]
2023-03-01 19:34:48 +00:00
OnlySupportsThisInputType {
exp_input_type : String ,
wrong_type : String ,
#[ label( " only {exp_input_type} input data is supported " ) ]
dst_span : Span ,
#[ label( " input type: {wrong_type} " ) ]
src_span : Span ,
} ,
Standardise the use of ShellError::UnsupportedInput and ShellError::TypeMismatch and add spans to every instance of the former (#7217)
# Description
* I was dismayed to discover recently that UnsupportedInput and
TypeMismatch are used *extremely* inconsistently across the codebase.
UnsupportedInput is sometimes used for input type-checks (as per the
name!!), but *also* used for argument type-checks. TypeMismatch is also
used for both.
I thus devised the following standard: input type-checking *only* uses
UnsupportedInput, and argument type-checking *only* uses TypeMismatch.
Moreover, to differentiate them, UnsupportedInput now has *two* error
arrows (spans), one pointing at the command and the other at the input
origin, while TypeMismatch only has the one (because the command should
always be nearby)
* In order to apply that standard, a very large number of
UnsupportedInput uses were changed so that the input's span could be
retrieved and delivered to it.
* Additionally, I noticed many places where **errors are not propagated
correctly**: there are lots of `match` sites which take a Value::Error,
then throw it away and replace it with a new Value::Error with
less/misleading information (such as reporting the error as an
"incorrect type"). I believe that the earliest errors are the most
important, and should always be propagated where possible.
* Also, to standardise one broad subset of UnsupportedInput error
messages, who all used slightly different wordings of "expected
`<type>`, got `<type>`", I created OnlySupportsThisInputType as a
variant of it.
* Finally, a bunch of error sites that had "repeated spans" - i.e. where
an error expected two spans, but `call.head` was given for both - were
fixed to use different spans.
# Example
BEFORE
```
〉20b | str starts-with 'a'
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #31:1:1]
1 │ 20b | str starts-with 'a'
· ┬
· ╰── Input's type is filesize. This command only works with strings.
╰────
〉'a' | math cos
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #33:1:1]
1 │ 'a' | math cos
· ─┬─
· ╰── Only numerical values are supported, input type: String
╰────
〉0x[12] | encode utf8
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #38:1:1]
1 │ 0x[12] | encode utf8
· ───┬──
· ╰── non-string input
╰────
```
AFTER
```
〉20b | str starts-with 'a'
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #1:1:1]
1 │ 20b | str starts-with 'a'
· ┬ ───────┬───────
· │ ╰── only string input data is supported
· ╰── input type: filesize
╰────
〉'a' | math cos
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #2:1:1]
1 │ 'a' | math cos
· ─┬─ ────┬───
· │ ╰── only numeric input data is supported
· ╰── input type: string
╰────
〉0x[12] | encode utf8
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #3:1:1]
1 │ 0x[12] | encode utf8
· ───┬── ───┬──
· │ ╰── only string input data is supported
· ╰── input type: binary
╰────
```
# User-Facing Changes
Various error messages suddenly make more sense (i.e. have two arrows
instead of one).
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2022-12-23 06:48:53 +00:00
/// No input value was piped into the command.
///
/// ## Resolution
///
/// Only use this command to process values from a previous expression.
#[ error( " Pipeline empty. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::pipeline_mismatch)) ]
2023-03-01 19:34:48 +00:00
PipelineEmpty {
#[ label( " no input value was piped in " ) ]
dst_span : Span ,
} ,
Standardise the use of ShellError::UnsupportedInput and ShellError::TypeMismatch and add spans to every instance of the former (#7217)
# Description
* I was dismayed to discover recently that UnsupportedInput and
TypeMismatch are used *extremely* inconsistently across the codebase.
UnsupportedInput is sometimes used for input type-checks (as per the
name!!), but *also* used for argument type-checks. TypeMismatch is also
used for both.
I thus devised the following standard: input type-checking *only* uses
UnsupportedInput, and argument type-checking *only* uses TypeMismatch.
Moreover, to differentiate them, UnsupportedInput now has *two* error
arrows (spans), one pointing at the command and the other at the input
origin, while TypeMismatch only has the one (because the command should
always be nearby)
* In order to apply that standard, a very large number of
UnsupportedInput uses were changed so that the input's span could be
retrieved and delivered to it.
* Additionally, I noticed many places where **errors are not propagated
correctly**: there are lots of `match` sites which take a Value::Error,
then throw it away and replace it with a new Value::Error with
less/misleading information (such as reporting the error as an
"incorrect type"). I believe that the earliest errors are the most
important, and should always be propagated where possible.
* Also, to standardise one broad subset of UnsupportedInput error
messages, who all used slightly different wordings of "expected
`<type>`, got `<type>`", I created OnlySupportsThisInputType as a
variant of it.
* Finally, a bunch of error sites that had "repeated spans" - i.e. where
an error expected two spans, but `call.head` was given for both - were
fixed to use different spans.
# Example
BEFORE
```
〉20b | str starts-with 'a'
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #31:1:1]
1 │ 20b | str starts-with 'a'
· ┬
· ╰── Input's type is filesize. This command only works with strings.
╰────
〉'a' | math cos
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #33:1:1]
1 │ 'a' | math cos
· ─┬─
· ╰── Only numerical values are supported, input type: String
╰────
〉0x[12] | encode utf8
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #38:1:1]
1 │ 0x[12] | encode utf8
· ───┬──
· ╰── non-string input
╰────
```
AFTER
```
〉20b | str starts-with 'a'
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #1:1:1]
1 │ 20b | str starts-with 'a'
· ┬ ───────┬───────
· │ ╰── only string input data is supported
· ╰── input type: filesize
╰────
〉'a' | math cos
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #2:1:1]
1 │ 'a' | math cos
· ─┬─ ────┬───
· │ ╰── only numeric input data is supported
· ╰── input type: string
╰────
〉0x[12] | encode utf8
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #3:1:1]
1 │ 0x[12] | encode utf8
· ───┬── ───┬──
· │ ╰── only string input data is supported
· ╰── input type: binary
╰────
```
# User-Facing Changes
Various error messages suddenly make more sense (i.e. have two arrows
instead of one).
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2022-12-23 06:48:53 +00:00
2023-03-01 19:34:48 +00:00
// TODO: remove non type error usages
2022-04-14 05:08:46 +00:00
/// A command received an argument of the wrong type.
///
/// ## Resolution
///
/// Convert the argument type before passing it in, or change the command to accept the type.
Standardise the use of ShellError::UnsupportedInput and ShellError::TypeMismatch and add spans to every instance of the former (#7217)
# Description
* I was dismayed to discover recently that UnsupportedInput and
TypeMismatch are used *extremely* inconsistently across the codebase.
UnsupportedInput is sometimes used for input type-checks (as per the
name!!), but *also* used for argument type-checks. TypeMismatch is also
used for both.
I thus devised the following standard: input type-checking *only* uses
UnsupportedInput, and argument type-checking *only* uses TypeMismatch.
Moreover, to differentiate them, UnsupportedInput now has *two* error
arrows (spans), one pointing at the command and the other at the input
origin, while TypeMismatch only has the one (because the command should
always be nearby)
* In order to apply that standard, a very large number of
UnsupportedInput uses were changed so that the input's span could be
retrieved and delivered to it.
* Additionally, I noticed many places where **errors are not propagated
correctly**: there are lots of `match` sites which take a Value::Error,
then throw it away and replace it with a new Value::Error with
less/misleading information (such as reporting the error as an
"incorrect type"). I believe that the earliest errors are the most
important, and should always be propagated where possible.
* Also, to standardise one broad subset of UnsupportedInput error
messages, who all used slightly different wordings of "expected
`<type>`, got `<type>`", I created OnlySupportsThisInputType as a
variant of it.
* Finally, a bunch of error sites that had "repeated spans" - i.e. where
an error expected two spans, but `call.head` was given for both - were
fixed to use different spans.
# Example
BEFORE
```
〉20b | str starts-with 'a'
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #31:1:1]
1 │ 20b | str starts-with 'a'
· ┬
· ╰── Input's type is filesize. This command only works with strings.
╰────
〉'a' | math cos
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #33:1:1]
1 │ 'a' | math cos
· ─┬─
· ╰── Only numerical values are supported, input type: String
╰────
〉0x[12] | encode utf8
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #38:1:1]
1 │ 0x[12] | encode utf8
· ───┬──
· ╰── non-string input
╰────
```
AFTER
```
〉20b | str starts-with 'a'
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #1:1:1]
1 │ 20b | str starts-with 'a'
· ┬ ───────┬───────
· │ ╰── only string input data is supported
· ╰── input type: filesize
╰────
〉'a' | math cos
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #2:1:1]
1 │ 'a' | math cos
· ─┬─ ────┬───
· │ ╰── only numeric input data is supported
· ╰── input type: string
╰────
〉0x[12] | encode utf8
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #3:1:1]
1 │ 0x[12] | encode utf8
· ───┬── ───┬──
· │ ╰── only string input data is supported
· ╰── input type: binary
╰────
```
# User-Facing Changes
Various error messages suddenly make more sense (i.e. have two arrows
instead of one).
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2022-12-23 06:48:53 +00:00
#[ error( " Type mismatch. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::type_mismatch)) ]
2023-03-06 10:31:07 +00:00
TypeMismatch {
2022-10-25 01:22:57 +00:00
err_message : String ,
#[ label = " {err_message} " ]
span : Span ,
} ,
2023-02-12 13:25:40 +00:00
/// A command received an argument with correct type but incorrect value.
///
/// ## Resolution
///
/// Correct the argument value before passing it in or change the command.
#[ error( " Incorrect value. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::incorrect_value)) ]
2023-03-06 10:31:07 +00:00
IncorrectValue {
msg : String ,
#[ label = " {msg} " ]
2023-08-18 17:47:05 +00:00
val_span : Span ,
#[ label = " encountered here " ]
call_span : Span ,
2023-03-06 10:31:07 +00:00
} ,
2023-02-12 13:25:40 +00:00
2022-04-14 05:08:46 +00:00
/// This value cannot be used with this operator.
///
/// ## Resolution
///
/// Not all values, for example custom values, can be used with all operators. Either
/// implement support for the operator on this type, or convert the type to a supported one.
2023-03-06 10:31:07 +00:00
#[ error( " Unsupported operator: {operator}. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::unsupported_operator)) ]
2023-03-06 10:31:07 +00:00
UnsupportedOperator {
operator : Operator ,
#[ label = " unsupported operator " ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2023-03-06 10:31:07 +00:00
/// Invalid assignment left-hand side
2022-11-11 06:51:08 +00:00
///
/// ## Resolution
///
/// Assignment requires that you assign to a variable or variable cell path.
#[ error( " Assignment operations require a variable. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::assignment_requires_variable)) ]
2023-03-06 10:31:07 +00:00
AssignmentRequiresVar {
#[ label = " needs to be a variable " ]
lhs_span : Span ,
} ,
2022-11-11 06:51:08 +00:00
2023-03-06 10:31:07 +00:00
/// Invalid assignment left-hand side
2022-11-11 06:51:08 +00:00
///
/// ## Resolution
///
/// Assignment requires that you assign to a mutable variable or cell path.
#[ error( " Assignment to an immutable variable. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::assignment_requires_mutable_variable)) ]
2023-03-06 10:31:07 +00:00
AssignmentRequiresMutableVar {
#[ label = " needs to be a mutable variable " ]
lhs_span : Span ,
} ,
2022-11-11 06:51:08 +00:00
2022-04-14 05:08:46 +00:00
/// An operator was not recognized during evaluation.
///
/// ## Resolution
///
/// Did you write the correct operator?
2023-03-06 10:31:07 +00:00
#[ error( " Unknown operator: {op_token}. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::unknown_operator)) ]
2023-03-06 10:31:07 +00:00
UnknownOperator {
op_token : String ,
#[ label = " unknown operator " ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2022-04-14 05:08:46 +00:00
/// An expected command parameter is missing.
///
/// ## Resolution
///
/// Add the expected parameter and try again.
2023-03-06 10:31:07 +00:00
#[ error( " Missing parameter: {param_name}. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::missing_parameter)) ]
2023-03-06 10:31:07 +00:00
MissingParameter {
param_name : String ,
#[ label = " missing parameter: {param_name} " ]
span : Span ,
} ,
2021-10-07 22:20:23 +00:00
2022-04-14 05:08:46 +00:00
/// Two parameters conflict with each other or are otherwise mutually exclusive.
///
/// ## Resolution
///
/// Remove one of the parameters/options and try again.
2021-10-10 04:13:15 +00:00
#[ error( " Incompatible parameters. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::incompatible_parameters)) ]
2021-10-10 04:13:15 +00:00
IncompatibleParameters {
left_message : String ,
2022-04-14 05:08:46 +00:00
// Be cautious, as flags can share the same span, resulting in a panic (ex: `rm -pt`)
2021-10-10 04:13:15 +00:00
#[ label( " {left_message} " ) ]
left_span : Span ,
right_message : String ,
#[ label( " {right_message} " ) ]
right_span : Span ,
} ,
2022-04-14 05:08:46 +00:00
/// There's some issue with number or matching of delimiters in an expression.
///
/// ## Resolution
///
/// Check your syntax for mismatched braces, RegExp syntax errors, etc, based on the specific error message.
2021-11-09 20:17:37 +00:00
#[ error( " Delimiter error " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::delimiter_error)) ]
2023-03-06 10:31:07 +00:00
DelimiterError {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2021-11-09 20:17:37 +00:00
2022-04-14 05:08:46 +00:00
/// An operation received parameters with some sort of incompatibility
/// (for example, different number of rows in a table, incompatible column names, etc).
///
/// ## Resolution
///
/// Refer to the specific error message for details on what's incompatible and then fix your
/// inputs to make sure they match that way.
2021-10-10 04:13:15 +00:00
#[ error( " Incompatible parameters. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::incompatible_parameters)) ]
2023-03-06 10:31:07 +00:00
IncompatibleParametersSingle {
msg : String ,
#[ label = " {msg} " ]
span : Span ,
} ,
2021-10-10 04:13:15 +00:00
2022-04-14 05:08:46 +00:00
/// You're trying to run an unsupported external command.
///
/// ## Resolution
///
/// Make sure there's an appropriate `run-external` declaration for this external command.
2022-02-20 21:26:41 +00:00
#[ error( " Running external commands not supported " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::external_commands)) ]
2023-03-06 17:33:09 +00:00
ExternalNotSupported {
#[ label = " external not supported " ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2023-03-06 17:33:09 +00:00
// TODO: consider moving to a more generic error variant for invalid values
2022-04-14 05:08:46 +00:00
/// The given probability input is invalid. The probability must be between 0 and 1.
///
/// ## Resolution
///
/// Make sure the probability is between 0 and 1 and try again.
2021-11-30 06:12:19 +00:00
#[ error( " Invalid Probability. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::invalid_probability)) ]
2023-03-06 17:33:09 +00:00
InvalidProbability {
#[ label = " invalid probability: must be between 0 and 1 " ]
span : Span ,
} ,
2021-11-30 06:12:19 +00:00
2022-04-14 05:08:46 +00:00
/// The first value in a `..` range must be compatible with the second one.
///
/// ## Resolution
///
/// Check to make sure both values are compatible, and that the values are enumerable in Nushell.
2023-03-01 19:34:48 +00:00
#[ error( " Invalid range {left_flank}..{right_flank} " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::invalid_range)) ]
2023-03-01 19:34:48 +00:00
InvalidRange {
left_flank : String ,
right_flank : String ,
#[ label = " expected a valid range " ]
span : Span ,
} ,
2021-12-02 17:26:12 +00:00
2022-04-14 05:08:46 +00:00
/// Catastrophic nushell failure. This reflects a completely unexpected or unrecoverable error.
///
/// ## Resolution
///
2023-07-30 20:50:25 +00:00
/// It is very likely that this is a bug. Please file an issue at <https://github.com/nushell/nushell/issues> with relevant information.
2023-03-06 17:33:09 +00:00
#[ error( " Nushell failed: {msg}. " ) ]
#[ diagnostic(
code ( nu ::shell ::nushell_failed ) ,
help (
" This shouldn't happen. Please file an issue: https://github.com/nushell/nushell/issues "
) ) ]
2022-05-07 19:39:22 +00:00
// Only use this one if Nushell completely falls over and hits a state that isn't possible or isn't recoverable
2023-03-06 17:33:09 +00:00
NushellFailed { msg : String } ,
2021-09-20 21:37:26 +00:00
2022-04-14 05:08:46 +00:00
/// Catastrophic nushell failure. This reflects a completely unexpected or unrecoverable error.
///
/// ## Resolution
///
2023-07-30 20:50:25 +00:00
/// It is very likely that this is a bug. Please file an issue at <https://github.com/nushell/nushell/issues> with relevant information.
2023-03-06 17:33:09 +00:00
#[ error( " Nushell failed: {msg}. " ) ]
#[ diagnostic(
code ( nu ::shell ::nushell_failed_spanned ) ,
help (
" This shouldn't happen. Please file an issue: https://github.com/nushell/nushell/issues "
) ) ]
2022-05-07 19:39:22 +00:00
// Only use this one if Nushell completely falls over and hits a state that isn't possible or isn't recoverable
2023-03-06 17:33:09 +00:00
NushellFailedSpanned {
msg : String ,
label : String ,
#[ label = " {label} " ]
span : Span ,
} ,
2022-01-24 19:43:38 +00:00
2022-05-07 19:39:22 +00:00
/// Catastrophic nushell failure. This reflects a completely unexpected or unrecoverable error.
///
/// ## Resolution
///
2023-07-30 20:50:25 +00:00
/// It is very likely that this is a bug. Please file an issue at <https://github.com/nushell/nushell/issues> with relevant information.
2023-03-06 17:33:09 +00:00
#[ error( " Nushell failed: {msg}. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::nushell_failed_help)) ]
2022-05-07 19:39:22 +00:00
// Only use this one if Nushell completely falls over and hits a state that isn't possible or isn't recoverable
2023-03-06 17:33:09 +00:00
NushellFailedHelp {
msg : String ,
#[ help ]
help : String ,
} ,
2022-05-07 19:39:22 +00:00
2022-04-14 05:08:46 +00:00
/// A referenced variable was not found at runtime.
///
/// ## Resolution
///
/// Check the variable name. Did you typo it? Did you forget to declare it? Is the casing right?
2021-12-15 22:56:12 +00:00
#[ error( " Variable not found " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::variable_not_found)) ]
2023-03-06 17:33:09 +00:00
VariableNotFoundAtRuntime {
#[ label = " variable not found " ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2022-04-14 05:08:46 +00:00
/// A referenced environment variable was not found at runtime.
///
/// ## Resolution
///
/// Check the environment variable name. Did you typo it? Did you forget to declare it? Is the casing right?
2023-03-06 17:33:09 +00:00
#[ error( " Environment variable '{envvar_name}' not found " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::env_variable_not_found)) ]
2023-03-06 17:33:09 +00:00
EnvVarNotFoundAtRuntime {
envvar_name : String ,
#[ label = " environment variable not found " ]
span : Span ,
} ,
2021-11-15 23:16:06 +00:00
2022-05-07 19:39:22 +00:00
/// A referenced module was not found at runtime.
///
/// ## Resolution
///
/// Check the module name. Did you typo it? Did you forget to declare it? Is the casing right?
2023-03-06 17:33:09 +00:00
#[ error( " Module '{mod_name}' not found " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::module_not_found)) ]
2023-03-06 17:33:09 +00:00
ModuleNotFoundAtRuntime {
mod_name : String ,
#[ label = " module not found " ]
span : Span ,
} ,
2022-05-07 19:39:22 +00:00
/// A referenced overlay was not found at runtime.
///
/// ## Resolution
///
/// Check the overlay name. Did you typo it? Did you forget to declare it? Is the casing right?
2023-03-06 17:33:09 +00:00
#[ error( " Overlay '{overlay_name}' not found " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::overlay_not_found)) ]
2023-03-06 17:33:09 +00:00
OverlayNotFoundAtRuntime {
overlay_name : String ,
#[ label = " overlay not found " ]
span : Span ,
} ,
2022-05-07 19:39:22 +00:00
2022-04-14 05:08:46 +00:00
/// The given item was not found. This is a fairly generic error that depends on context.
///
/// ## Resolution
///
/// This error is triggered in various places, and simply signals that "something" was not found. Refer to the specific error message for further details.
2021-11-15 23:16:06 +00:00
#[ error( " Not found. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::parser::not_found)) ]
2023-03-06 17:33:09 +00:00
NotFound {
#[ label = " did not find anything under this name " ]
span : Span ,
} ,
2021-11-15 23:16:06 +00:00
2022-04-14 05:08:46 +00:00
/// Failed to convert a value of one type into a different type.
///
/// ## Resolution
///
/// Not all values can be coerced this way. Check the supported type(s) and try again.
2023-03-06 17:33:09 +00:00
#[ error( " Can't convert to {to_type}. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::cant_convert)) ]
2023-03-06 17:33:09 +00:00
CantConvert {
to_type : String ,
from_type : String ,
#[ label( " can't convert {from_type} to {to_type} " ) ]
span : Span ,
#[ help ]
help : Option < String > ,
} ,
2022-03-24 12:04:31 +00:00
2023-05-24 22:58:18 +00:00
#[ error( " Can't convert string `{details}` to duration. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::cant_convert_with_value)) ]
2023-05-24 22:58:18 +00:00
CantConvertToDuration {
2023-03-06 17:33:09 +00:00
details : String ,
2023-05-24 22:58:18 +00:00
#[ label( " can't be converted to duration " ) ]
2023-03-06 17:33:09 +00:00
dst_span : Span ,
2023-05-24 22:58:18 +00:00
#[ label( " this string value... " ) ]
2023-03-06 17:33:09 +00:00
src_span : Span ,
#[ help ]
help : Option < String > ,
} ,
2022-07-07 10:54:38 +00:00
2022-04-14 05:08:46 +00:00
/// An environment variable cannot be represented as a string.
///
/// ## Resolution
///
/// Not all types can be converted to environment variable values, which must be strings. Check the input type and try again.
2023-03-06 17:33:09 +00:00
#[ error( " '{envvar_name}' is not representable as a string. " ) ]
2022-03-11 22:18:39 +00:00
#[ diagnostic(
2023-03-06 17:33:09 +00:00
code ( nu ::shell ::env_var_not_a_string ) ,
help (
r #" The '{envvar_name}' environment variable must be a string or be convertible to a string.
Either make sure ' { envvar_name } ' is a string , or add a ' to_string ' entry for it in ENV_CONVERSIONS . " #
)
) ]
EnvVarNotAString {
envvar_name : String ,
#[ label( " value not representable as a string " ) ]
span : Span ,
} ,
2022-03-11 22:18:39 +00:00
2022-08-31 20:32:56 +00:00
/// This environment variable cannot be set manually.
///
/// ## Resolution
///
/// This environment variable is set automatically by Nushell and cannot not be set manually.
2023-03-06 17:33:09 +00:00
#[ error( " {envvar_name} cannot be set manually. " ) ]
2022-08-31 20:32:56 +00:00
#[ diagnostic(
code ( nu ::shell ::automatic_env_var_set_manually ) ,
help (
2023-08-14 10:49:55 +00:00
r # "The environment variable '{envvar_name}' is set automatically by Nushell and cannot be set manually."#
2022-08-31 20:32:56 +00:00
)
) ]
2023-03-06 17:33:09 +00:00
AutomaticEnvVarSetManually {
envvar_name : String ,
#[ label( " cannot set '{envvar_name}' manually " ) ]
span : Span ,
} ,
2022-08-31 20:32:56 +00:00
2023-01-28 19:17:32 +00:00
/// It is not possible to replace the entire environment at once
///
/// ## Resolution
///
/// Setting the entire environment is not allowed. Change environment variables individually
/// instead.
#[ error( " Cannot replace environment. " ) ]
#[ diagnostic(
code ( nu ::shell ::cannot_replace_env ) ,
2023-03-06 17:33:09 +00:00
help ( r # "Assigning a value to '$env' is not allowed."# )
2023-01-28 19:17:32 +00:00
) ]
2023-03-06 17:33:09 +00:00
CannotReplaceEnv {
#[ label( " setting '$env' not allowed " ) ]
span : Span ,
} ,
2023-01-28 19:17:32 +00:00
2022-04-14 05:08:46 +00:00
/// Division by zero is not a thing.
///
/// ## Resolution
///
/// Add a guard of some sort to check whether a denominator input to this division is zero, and branch off if that's the case.
2021-09-20 21:37:26 +00:00
#[ error( " Division by zero. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::division_by_zero)) ]
2023-03-06 17:33:09 +00:00
DivisionByZero {
#[ label( " division by zero " ) ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2024-04-04 07:59:21 +00:00
/// An error happened while trying to create a range.
2022-04-14 05:08:46 +00:00
///
/// This can happen in various unexpected situations, for example if the range would loop forever (as would be the case with a 0-increment).
///
/// ## Resolution
///
/// Check your range values to make sure they're countable and would not loop forever.
2021-09-20 21:37:26 +00:00
#[ error( " Can't convert range to countable values " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::range_to_countable)) ]
2023-03-06 17:33:09 +00:00
CannotCreateRange {
#[ label = " can't convert to countable values " ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2022-04-14 05:08:46 +00:00
/// You attempted to access an index beyond the available length of a value.
///
/// ## Resolution
///
/// Check your lengths and try again.
2023-03-06 17:33:09 +00:00
#[ error( " Row number too large (max: {max_idx}). " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::access_beyond_end)) ]
2023-03-06 17:33:09 +00:00
AccessBeyondEnd {
max_idx : usize ,
#[ label = " index too large (max: {max_idx}) " ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2022-12-06 17:51:55 +00:00
/// You attempted to insert data at a list position higher than the end.
///
/// ## Resolution
///
/// To insert data into a list, assign to the last used index + 1.
2023-03-06 17:33:09 +00:00
#[ error( " Inserted at wrong row number (should be {available_idx}). " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::access_beyond_end)) ]
2023-03-06 17:33:09 +00:00
InsertAfterNextFreeIndex {
available_idx : usize ,
#[ label = " can't insert at index (the next available index is {available_idx}) " ]
span : Span ,
} ,
2022-12-06 17:51:55 +00:00
2022-10-29 17:47:50 +00:00
/// You attempted to access an index when it's empty.
///
/// ## Resolution
///
/// Check your lengths and try again.
#[ error( " Row number too large (empty content). " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::access_beyond_end)) ]
2023-03-06 17:33:09 +00:00
AccessEmptyContent {
#[ label = " index too large (empty content) " ]
span : Span ,
} ,
2022-10-29 17:47:50 +00:00
2023-03-06 17:33:09 +00:00
// TODO: check to be taken over by `AccessBeyondEnd`
2022-04-14 05:08:46 +00:00
/// You attempted to access an index beyond the available length of a stream.
///
/// ## Resolution
///
/// Check your lengths and try again.
2021-09-20 21:37:26 +00:00
#[ error( " Row number too large. " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::access_beyond_end_of_stream)) ]
2023-03-06 17:33:09 +00:00
AccessBeyondEndOfStream {
#[ label = " index too large " ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2022-04-14 05:08:46 +00:00
/// Tried to index into a type that does not support pathed access.
///
/// ## Resolution
///
/// Check your types. Only composite types can be pathed into.
2021-09-20 21:37:26 +00:00
#[ error( " Data cannot be accessed with a cell path " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::incompatible_path_access)) ]
2023-03-06 17:33:09 +00:00
IncompatiblePathAccess {
type_name : String ,
#[ label( " {type_name} doesn't support cell paths " ) ]
span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2022-04-14 05:08:46 +00:00
/// The requested column does not exist.
///
/// ## Resolution
///
/// Check the spelling of your column name. Did you forget to rename a column somewhere?
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-17 23:05:11 +00:00
#[ error( " Cannot find column '{col_name}' " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::column_not_found)) ]
2023-03-06 17:33:09 +00:00
CantFindColumn {
col_name : String ,
#[ label = " cannot find column '{col_name}' " ]
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-17 23:05:11 +00:00
span : Option < Span > ,
2023-03-06 17:33:09 +00:00
#[ label = " value originates here " ]
src_span : Span ,
} ,
2021-09-20 21:37:26 +00:00
2022-04-14 05:08:46 +00:00
/// Attempted to insert a column into a table, but a column with that name already exists.
///
/// ## Resolution
///
/// Drop or rename the existing column (check `rename -h`) and try again.
2022-03-17 17:55:02 +00:00
#[ error( " Column already exists " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::column_already_exists)) ]
2023-03-06 17:33:09 +00:00
ColumnAlreadyExists {
col_name : String ,
#[ label = " column '{col_name}' already exists " ]
span : Span ,
#[ label = " value originates here " ]
src_span : Span ,
} ,
2022-03-17 17:55:02 +00:00
2022-04-14 05:08:46 +00:00
/// The given operation can only be performed on lists.
///
/// ## Resolution
///
/// Check the input type to this command. Are you sure it's a list?
2021-11-05 03:59:12 +00:00
#[ error( " Not a list value " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::not_a_list)) ]
2023-03-06 17:33:09 +00:00
NotAList {
#[ label = " value not a list " ]
dst_span : Span ,
#[ label = " value originates here " ]
src_span : Span ,
} ,
2021-11-05 03:59:12 +00:00
2023-04-01 18:09:33 +00:00
/// Fields can only be defined once
///
/// ## Resolution
///
/// Check the record to ensure you aren't reusing the same field name
Spread operator in record literals (#11144)
Goes towards implementing #10598, which asks for a spread operator in
lists, in records, and when calling commands (continuation of #11006,
which only implements it in lists)
# Description
This PR is for adding a spread operator that can be used when building
records. Additional functionality can be added later.
Changes:
- Previously, the `Expr::Record` variant held `(Expression, Expression)`
pairs. It now holds instances of an enum `RecordItem` (the name isn't
amazing) that allows either a key-value mapping or a spread operator.
- `...` will be treated as the spread operator when it appears before
`$`, `{`, or `(` inside records (no whitespace allowed in between) (not
implemented yet)
- The error message for duplicate columns now includes the column name
itself, because if two spread records are involved in such an error, you
can't tell which field was duplicated from the spans alone
`...` will still be treated as a normal string outside records, and even
in records, it is not treated as a spread operator when not followed
immediately by a `$`, `{`, or `(`.
# User-Facing Changes
Users will be able to use `...` when building records.
```
> let rec = { x: 1, ...{ a: 2 } }
> $rec
╭───┬───╮
│ x │ 1 │
│ a │ 2 │
╰───┴───╯
> { foo: bar, ...$rec, baz: blah }
╭─────┬──────╮
│ foo │ bar │
│ x │ 1 │
│ a │ 2 │
│ baz │ blah │
╰─────┴──────╯
```
If you want to update a field of a record, you'll have to use `merge`
instead:
```
> { ...$rec, x: 5 }
Error: nu::shell::column_defined_twice
× Record field or table column used twice: x
╭─[entry #2:1:1]
1 │ { ...$rec, x: 5 }
· ──┬─ ┬
· │ ╰── field redefined here
· ╰── field first defined here
╰────
> $rec | merge { x: 5 }
╭───┬───╮
│ x │ 5 │
│ a │ 2 │
╰───┴───╯
```
# Tests + Formatting
# After Submitting
2023-11-29 17:31:31 +00:00
#[ error( " Record field or table column used twice: {col_name} " ) ]
2023-11-01 20:25:35 +00:00
#[ diagnostic(code(nu::shell::column_defined_twice)) ]
2023-04-01 18:09:33 +00:00
ColumnDefinedTwice {
Spread operator in record literals (#11144)
Goes towards implementing #10598, which asks for a spread operator in
lists, in records, and when calling commands (continuation of #11006,
which only implements it in lists)
# Description
This PR is for adding a spread operator that can be used when building
records. Additional functionality can be added later.
Changes:
- Previously, the `Expr::Record` variant held `(Expression, Expression)`
pairs. It now holds instances of an enum `RecordItem` (the name isn't
amazing) that allows either a key-value mapping or a spread operator.
- `...` will be treated as the spread operator when it appears before
`$`, `{`, or `(` inside records (no whitespace allowed in between) (not
implemented yet)
- The error message for duplicate columns now includes the column name
itself, because if two spread records are involved in such an error, you
can't tell which field was duplicated from the spans alone
`...` will still be treated as a normal string outside records, and even
in records, it is not treated as a spread operator when not followed
immediately by a `$`, `{`, or `(`.
# User-Facing Changes
Users will be able to use `...` when building records.
```
> let rec = { x: 1, ...{ a: 2 } }
> $rec
╭───┬───╮
│ x │ 1 │
│ a │ 2 │
╰───┴───╯
> { foo: bar, ...$rec, baz: blah }
╭─────┬──────╮
│ foo │ bar │
│ x │ 1 │
│ a │ 2 │
│ baz │ blah │
╰─────┴──────╯
```
If you want to update a field of a record, you'll have to use `merge`
instead:
```
> { ...$rec, x: 5 }
Error: nu::shell::column_defined_twice
× Record field or table column used twice: x
╭─[entry #2:1:1]
1 │ { ...$rec, x: 5 }
· ──┬─ ┬
· │ ╰── field redefined here
· ╰── field first defined here
╰────
> $rec | merge { x: 5 }
╭───┬───╮
│ x │ 5 │
│ a │ 2 │
╰───┴───╯
```
# Tests + Formatting
# After Submitting
2023-11-29 17:31:31 +00:00
col_name : String ,
2023-04-01 18:09:33 +00:00
#[ label = " field redefined here " ]
second_use : Span ,
#[ label = " field first defined here " ]
first_use : Span ,
} ,
2024-02-03 11:23:16 +00:00
/// Attempted to create a record from different number of columns and values
///
/// ## Resolution
///
/// Check the record has the same number of columns as values
#[ error( " Attempted to create a record from different number of columns and values " ) ]
#[ diagnostic(code(nu::shell::record_cols_vals_mismatch)) ]
RecordColsValsMismatch {
#[ label = " problematic value " ]
bad_value : Span ,
#[ label = " attempted to create the record here " ]
creation_site : Span ,
} ,
2022-04-14 05:08:46 +00:00
/// An error happened while performing an external command.
///
/// ## Resolution
///
/// This error is fairly generic. Refer to the specific error message for further details.
2022-08-12 17:34:10 +00:00
#[ error( " External command failed " ) ]
2023-03-06 17:33:09 +00:00
#[ diagnostic(code(nu::shell::external_command), help( " {help} " )) ]
ExternalCommand {
label : String ,
help : String ,
#[ label( " {label} " ) ]
span : Span ,
} ,
2021-09-24 12:03:39 +00:00
2022-04-14 05:08:46 +00:00
/// An operation was attempted with an input unsupported for some reason.
///
/// ## Resolution
///
/// This error is fairly generic. Refer to the specific error message for further details.
2021-09-24 12:03:39 +00:00
#[ error( " Unsupported input " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::unsupported_input)) ]
2023-11-07 22:25:32 +00:00
UnsupportedInput {
msg : String ,
input : String ,
#[ label( " {msg} " ) ]
msg_span : Span ,
#[ label( " {input} " ) ]
input_span : Span ,
} ,
2021-10-01 21:53:13 +00:00
2022-04-14 05:08:46 +00:00
/// Failed to parse an input into a datetime value.
///
/// ## Resolution
///
/// Make sure your datetime input format is correct.
///
/// For example, these are some valid formats:
///
/// * "5 pm"
/// * "2020/12/4"
/// * "2020.12.04 22:10 +2"
/// * "2020-04-12 22:10:57 +02:00"
/// * "2020-04-12T22:10:57.213231+02:00"
/// * "Tue, 1 Jul 2003 10:52:37 +0200""#
2023-11-08 12:04:02 +00:00
#[ error( " Unable to parse datetime: [{msg}]. " ) ]
2022-02-28 01:21:46 +00:00
#[ diagnostic(
code ( nu ::shell ::datetime_parse_error ) ,
help (
r #" Examples of supported inputs:
* " 5 pm "
* " 2020/12/4 "
* " 2020.12.04 22:10 +2 "
* " 2020-04-12 22:10:57 +02:00 "
* " 2020-04-12T22:10:57.213231+02:00 "
* " Tue, 1 Jul 2003 10:52:37 +0200 " " #
)
) ]
2023-11-08 12:04:02 +00:00
DatetimeParseError {
msg : String ,
#[ label( " datetime parsing failed " ) ]
span : Span ,
} ,
2022-02-28 01:21:46 +00:00
2022-04-14 05:08:46 +00:00
/// A network operation failed.
///
/// ## Resolution
///
/// It's always DNS.
2022-01-04 02:01:18 +00:00
#[ error( " Network failure " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::network_failure)) ]
2023-11-19 20:32:11 +00:00
NetworkFailure {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-01-04 02:01:18 +00:00
2022-04-14 05:08:46 +00:00
/// Help text for this command could not be found.
///
/// ## Resolution
///
/// Check the spelling for the requested command and try again. Are you sure it's defined and your configurations are loading correctly? Can you execute it?
2021-10-09 01:02:01 +00:00
#[ error( " Command not found " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::command_not_found)) ]
2023-11-19 20:31:28 +00:00
CommandNotFound {
#[ label( " command not found " ) ]
span : Span ,
} ,
2021-10-09 01:02:01 +00:00
2022-12-30 15:44:37 +00:00
/// This alias could not be found
///
/// ## Resolution
///
/// The alias does not exist in the current scope. It might exist in another scope or overlay or be hidden.
#[ error( " Alias not found " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::alias_not_found)) ]
2023-11-21 08:24:08 +00:00
AliasNotFound {
#[ label( " alias not found " ) ]
span : Span ,
} ,
2022-12-30 15:44:37 +00:00
2022-04-14 05:08:46 +00:00
/// Failed to find a file during a nushell operation.
///
/// ## Resolution
///
/// Does the file in the error message exist? Is it readable and accessible? Is the casing right?
2021-10-05 03:43:07 +00:00
#[ error( " File not found " ) ]
2024-02-21 13:27:13 +00:00
#[ diagnostic(code(nu::shell::file_not_found), help( " {file} does not exist " )) ]
2023-11-21 09:08:10 +00:00
FileNotFound {
2024-02-21 13:27:13 +00:00
file : String ,
2023-11-21 09:08:10 +00:00
#[ label( " file not found " ) ]
span : Span ,
} ,
2021-10-05 03:43:07 +00:00
2022-04-14 05:08:46 +00:00
/// Failed to find a file during a nushell operation.
///
/// ## Resolution
///
/// Does the file in the error message exist? Is it readable and accessible? Is the casing right?
2021-10-05 21:08:39 +00:00
#[ error( " File not found " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::file_not_found)) ]
2023-11-21 23:30:21 +00:00
FileNotFoundCustom {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2021-10-05 21:08:39 +00:00
2024-04-24 22:40:39 +00:00
/// The registered plugin data for a plugin is invalid.
2024-04-21 12:36:26 +00:00
///
/// ## Resolution
///
2024-04-23 11:37:50 +00:00
/// `plugin add` the plugin again to update the data, or remove it with `plugin rm`.
2024-04-24 22:40:39 +00:00
#[ error( " The registered plugin data for `{plugin_name}` is invalid " ) ]
#[ diagnostic(code(nu::shell::plugin_registry_data_invalid)) ]
PluginRegistryDataInvalid {
2024-04-21 12:36:26 +00:00
plugin_name : String ,
2024-04-23 11:37:50 +00:00
#[ label( " plugin `{plugin_name}` loaded here " ) ]
span : Option < Span > ,
2024-04-24 22:40:39 +00:00
#[ help( " the format in the plugin registry file is not compatible with this version of Nushell. \n \n Try adding the plugin again with `{}` " ) ]
2024-04-23 11:37:50 +00:00
add_command : String ,
2024-04-21 12:36:26 +00:00
} ,
2022-04-14 05:08:46 +00:00
/// A plugin failed to load.
///
/// ## Resolution
///
2022-08-24 04:32:41 +00:00
/// This is a fairly generic error. Refer to the specific error message for further details.
2023-11-21 23:30:52 +00:00
#[ error( " Plugin failed to load: {msg} " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::plugin_failed_to_load)) ]
2023-11-21 23:30:52 +00:00
PluginFailedToLoad { msg : String } ,
2021-12-02 23:11:25 +00:00
2022-04-14 05:08:46 +00:00
/// A message from a plugin failed to encode.
///
/// ## Resolution
///
/// This is likely a bug with the plugin itself.
2023-11-21 23:38:58 +00:00
#[ error( " Plugin failed to encode: {msg} " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::plugin_failed_to_encode)) ]
2023-11-21 23:38:58 +00:00
PluginFailedToEncode { msg : String } ,
2021-12-05 03:11:19 +00:00
2022-04-14 05:08:46 +00:00
/// A message to a plugin failed to decode.
///
/// ## Resolution
///
/// This is either an issue with the inputs to a plugin (bad JSON?) or a bug in the plugin itself. Fix or report as appropriate.
2023-11-22 11:56:04 +00:00
#[ error( " Plugin failed to decode: {msg} " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::plugin_failed_to_decode)) ]
2023-11-22 11:56:04 +00:00
PluginFailedToDecode { msg : String } ,
2021-12-05 03:11:19 +00:00
2024-02-25 22:32:50 +00:00
/// A custom value cannot be sent to the given plugin.
///
/// ## Resolution
///
/// Custom values can only be used with the plugin they came from. Use a command from that
/// plugin instead.
#[ error( " Custom value `{name}` cannot be sent to plugin " ) ]
#[ diagnostic(code(nu::shell::custom_value_incorrect_for_plugin)) ]
CustomValueIncorrectForPlugin {
name : String ,
#[ label( " the `{dest_plugin}` plugin does not support this kind of value " ) ]
span : Span ,
dest_plugin : String ,
#[ help( " this value came from the `{}` plugin " ) ]
src_plugin : Option < String > ,
} ,
/// The plugin failed to encode a custom value.
///
/// ## Resolution
///
/// This is likely a bug with the plugin itself. The plugin may have tried to send a custom
/// value that is not serializable.
#[ error( " Custom value failed to encode " ) ]
#[ diagnostic(code(nu::shell::custom_value_failed_to_encode)) ]
CustomValueFailedToEncode {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
/// The plugin failed to encode a custom value.
///
/// ## Resolution
///
/// This may be a bug within the plugin, or the plugin may have been updated in between the
/// creation of the custom value and its use.
#[ error( " Custom value failed to decode " ) ]
#[ diagnostic(code(nu::shell::custom_value_failed_to_decode)) ]
#[ diagnostic(help(
" the plugin may have been updated and no longer support this custom value "
) ) ]
CustomValueFailedToDecode {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-08-24 04:32:41 +00:00
/// I/O operation interrupted.
///
/// ## Resolution
///
/// This is a generic error. Refer to the specific error message for further details.
#[ error( " I/O interrupted " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::io_interrupted)) ]
2023-11-28 12:43:51 +00:00
IOInterrupted {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-08-24 04:32:41 +00:00
2022-04-14 05:08:46 +00:00
/// An I/O operation failed.
///
/// ## Resolution
///
/// This is a generic error. Refer to the specific error message for further details.
2021-12-02 23:11:25 +00:00
#[ error( " I/O error " ) ]
2023-11-28 12:43:51 +00:00
#[ diagnostic(code(nu::shell::io_error), help( " {msg} " )) ]
IOError { msg : String } ,
2021-12-02 23:11:25 +00:00
2022-08-24 04:32:41 +00:00
/// An I/O operation failed.
///
/// ## Resolution
///
/// This is a generic error. Refer to the specific error message for further details.
#[ error( " I/O error " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::io_error)) ]
2023-11-28 12:43:51 +00:00
IOErrorSpanned {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-08-24 04:32:41 +00:00
fix: coredump without any messages (#13034)
<!--
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 https://github.com/nushell/nushell/issues/12874
- fixes https://github.com/nushell/nushell/issues/12874
I want to fix the issue which is induced by the fix for
https://github.com/nushell/nushell/issues/12369. after this pr. This pr
induced a new error for unix system, in order to show coredump messages
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 should close https://github.com/nushell/nushell/issues/12874
- fixes https://github.com/nushell/nushell/issues/12874
I want to fix the issue which is induced by the fix for
https://github.com/nushell/nushell/issues/12369. after this pr. This pr
induced a new error for unix system, in order to show coredump messages
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
after fix for 12874, coredump message is messing, so I want to fix it
# 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.
-->
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
2024-06-07 13:02:52 +00:00
#[ cfg(unix) ]
/// An I/O operation failed.
///
/// ## Resolution
///
/// This is a generic error. Refer to the specific error message for further details.
#[ error( " program coredump error " ) ]
#[ diagnostic(code(nu::shell::coredump_error)) ]
CoredumpErrorSpanned {
msg : String ,
signal : i32 ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-04-14 05:08:46 +00:00
/// Tried to `cd` to a path that isn't a directory.
///
/// ## Resolution
///
/// Make sure the path is a directory. It currently exists, but is of some other type, like a file.
2022-01-23 13:02:12 +00:00
#[ error( " Cannot change to directory " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::cannot_cd_to_directory)) ]
2023-11-28 12:43:51 +00:00
NotADirectory {
#[ label( " is not a directory " ) ]
span : Span ,
} ,
2022-01-23 13:02:12 +00:00
2022-04-14 05:08:46 +00:00
/// Attempted to perform an operation on a directory that doesn't exist.
///
/// ## Resolution
///
/// Make sure the directory in the error message actually exists before trying again.
2021-10-05 03:43:07 +00:00
#[ error( " Directory not found " ) ]
2023-11-28 12:43:51 +00:00
#[ diagnostic(code(nu::shell::directory_not_found), help( " {dir} does not exist " )) ]
DirectoryNotFound {
dir : String ,
#[ label( " directory not found " ) ]
span : Span ,
} ,
2021-10-05 03:43:07 +00:00
2022-04-14 05:08:46 +00:00
/// The requested move operation cannot be completed. This is typically because both paths exist,
/// but are of different types. For example, you might be trying to overwrite an existing file with
/// a directory.
///
/// ## Resolution
///
/// Make sure the destination path does not exist before moving a directory.
2021-10-05 03:43:07 +00:00
#[ error( " Move not possible " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::move_not_possible)) ]
2021-10-05 03:43:07 +00:00
MoveNotPossible {
source_message : String ,
#[ label( " {source_message} " ) ]
source_span : Span ,
destination_message : String ,
#[ label( " {destination_message} " ) ]
destination_span : Span ,
} ,
2021-10-05 19:54:30 +00:00
2022-04-14 05:08:46 +00:00
/// Failed to create either a file or directory.
///
/// ## Resolution
///
/// This is a fairly generic error. Refer to the specific error message for further details.
2021-10-07 21:18:03 +00:00
#[ error( " Create not possible " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::create_not_possible)) ]
2023-11-28 12:43:51 +00:00
CreateNotPossible {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2021-10-10 04:13:15 +00:00
2022-04-14 05:08:46 +00:00
/// Changing the access time ("atime") of this file is not possible.
///
/// ## Resolution
///
/// This can be for various reasons, such as your platform or permission flags. Refer to the specific error message for more details.
2022-04-07 11:44:05 +00:00
#[ error( " Not possible to change the access time " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::change_access_time_not_possible)) ]
2023-12-04 09:19:32 +00:00
ChangeAccessTimeNotPossible {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-04-07 11:44:05 +00:00
2022-04-14 05:08:46 +00:00
/// Changing the modification time ("mtime") of this file is not possible.
///
/// ## Resolution
///
/// This can be for various reasons, such as your platform or permission flags. Refer to the specific error message for more details.
2022-04-07 11:44:05 +00:00
#[ error( " Not possible to change the modified time " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::change_modified_time_not_possible)) ]
2023-12-04 09:19:32 +00:00
ChangeModifiedTimeNotPossible {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-04-07 11:44:05 +00:00
2022-04-14 05:08:46 +00:00
/// Unable to remove this item.
2023-06-18 08:00:12 +00:00
///
/// ## Resolution
///
/// Removal can fail for a number of reasons, such as permissions problems. Refer to the specific error message for more details.
2021-10-10 04:13:15 +00:00
#[ error( " Remove not possible " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::remove_not_possible)) ]
2023-12-04 09:19:32 +00:00
RemoveNotPossible {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2021-10-14 17:54:51 +00:00
2022-04-27 10:52:31 +00:00
/// Error while trying to read a file
///
/// ## Resolution
///
/// The error will show the result from a file operation
#[ error( " Error trying to read file " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::error_reading_file)) ]
2023-12-04 09:19:32 +00:00
ReadingFile {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-04-27 10:52:31 +00:00
2022-04-14 05:08:46 +00:00
/// A name was not found. Did you mean a different name?
///
/// ## Resolution
///
/// The error message will suggest a possible match for what you meant.
2021-11-07 21:48:50 +00:00
#[ error( " Name not found " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::name_not_found)) ]
2023-12-04 09:19:32 +00:00
DidYouMean {
suggestion : String ,
#[ label( " did you mean '{suggestion}'? " ) ]
span : Span ,
} ,
2021-11-15 23:16:06 +00:00
2022-08-13 09:55:06 +00:00
/// A name was not found. Did you mean a different name?
///
/// ## Resolution
///
/// The error message will suggest a possible match for what you meant.
2023-12-04 09:19:32 +00:00
#[ error( " {msg} " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::did_you_mean_custom)) ]
2023-12-04 09:19:32 +00:00
DidYouMeanCustom {
msg : String ,
suggestion : String ,
#[ label( " did you mean '{suggestion}'? " ) ]
span : Span ,
} ,
2022-08-13 09:55:06 +00:00
2022-04-14 05:08:46 +00:00
/// The given input must be valid UTF-8 for further processing.
///
/// ## Resolution
///
/// Check your input's encoding. Are there any funny characters/bytes?
2021-11-23 08:14:40 +00:00
#[ error( " Non-UTF8 string " ) ]
Add string/binary type color to `ByteStream` (#12897)
# Description
This PR allows byte streams to optionally be colored as being
specifically binary or string data, which guarantees that they'll be
converted to `Binary` or `String` appropriately on `into_value()`,
making them compatible with `Type` guarantees. This makes them
significantly more broadly usable for command input and output.
There is still an `Unknown` type for byte streams coming from external
commands, which uses the same behavior as we previously did where it's a
string if it's UTF-8.
A small number of commands were updated to take advantage of this, just
to prove the point. I will be adding more after this merges.
# User-Facing Changes
- New types in `describe`: `string (stream)`, `binary (stream)`
- These commands now return a stream if their input was a stream:
- `into binary`
- `into string`
- `bytes collect`
- `str join`
- `first` (binary)
- `last` (binary)
- `take` (binary)
- `skip` (binary)
- Streams that are explicitly binary colored will print as a streaming
hexdump
- example:
```nushell
1.. | each { into binary } | bytes collect
```
# Tests + Formatting
I've added some tests to cover it at a basic level, and it doesn't break
anything existing, but I do think more would be nice. Some of those will
come when I modify more commands to stream.
# After Submitting
There are a few things I'm not quite satisfied with:
- **String trimming behavior.** We automatically trim newlines from
streams from external commands, but I don't think we should do this with
internal commands. If I call a command that happens to turn my string
into a stream, I don't want the newline to suddenly disappear. I changed
this to specifically do it only on `Child` and `File`, but I don't know
if this is quite right, and maybe we should bring back the old flag for
`trim_end_newline`
- **Known binary always resulting in a hexdump.** It would be nice to
have a `print --raw`, so that we can put binary data on stdout
explicitly if we want to. This PR doesn't change how external commands
work though - they still dump straight to stdout.
Otherwise, here's the normal checklist:
- [ ] release notes
- [ ] docs update for plugin protocol changes (added `type` field)
---------
Co-authored-by: Ian Manske <ian.manske@pm.me>
2024-05-20 00:35:32 +00:00
#[ diagnostic(
code ( nu ::parser ::non_utf8 ) ,
help ( " see `decode` for handling character sets other than UTF-8 " )
) ]
2023-12-04 09:19:32 +00:00
NonUtf8 {
#[ label( " non-UTF8 string " ) ]
span : Span ,
} ,
2021-11-23 08:14:40 +00:00
2022-12-10 17:23:44 +00:00
/// The given input must be valid UTF-8 for further processing.
///
/// ## Resolution
///
/// Check your input's encoding. Are there any funny characters/bytes?
#[ error( " Non-UTF8 string " ) ]
Add string/binary type color to `ByteStream` (#12897)
# Description
This PR allows byte streams to optionally be colored as being
specifically binary or string data, which guarantees that they'll be
converted to `Binary` or `String` appropriately on `into_value()`,
making them compatible with `Type` guarantees. This makes them
significantly more broadly usable for command input and output.
There is still an `Unknown` type for byte streams coming from external
commands, which uses the same behavior as we previously did where it's a
string if it's UTF-8.
A small number of commands were updated to take advantage of this, just
to prove the point. I will be adding more after this merges.
# User-Facing Changes
- New types in `describe`: `string (stream)`, `binary (stream)`
- These commands now return a stream if their input was a stream:
- `into binary`
- `into string`
- `bytes collect`
- `str join`
- `first` (binary)
- `last` (binary)
- `take` (binary)
- `skip` (binary)
- Streams that are explicitly binary colored will print as a streaming
hexdump
- example:
```nushell
1.. | each { into binary } | bytes collect
```
# Tests + Formatting
I've added some tests to cover it at a basic level, and it doesn't break
anything existing, but I do think more would be nice. Some of those will
come when I modify more commands to stream.
# After Submitting
There are a few things I'm not quite satisfied with:
- **String trimming behavior.** We automatically trim newlines from
streams from external commands, but I don't think we should do this with
internal commands. If I call a command that happens to turn my string
into a stream, I don't want the newline to suddenly disappear. I changed
this to specifically do it only on `Child` and `File`, but I don't know
if this is quite right, and maybe we should bring back the old flag for
`trim_end_newline`
- **Known binary always resulting in a hexdump.** It would be nice to
have a `print --raw`, so that we can put binary data on stdout
explicitly if we want to. This PR doesn't change how external commands
work though - they still dump straight to stdout.
Otherwise, here's the normal checklist:
- [ ] release notes
- [ ] docs update for plugin protocol changes (added `type` field)
---------
Co-authored-by: Ian Manske <ian.manske@pm.me>
2024-05-20 00:35:32 +00:00
#[ diagnostic(
code ( nu ::parser ::non_utf8_custom ) ,
help ( " see `decode` for handling character sets other than UTF-8 " )
) ]
2023-12-04 09:19:32 +00:00
NonUtf8Custom {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-12-10 17:23:44 +00:00
2022-04-14 05:08:46 +00:00
/// The value given for this configuration is not supported.
///
/// ## Resolution
///
/// Refer to the specific error message for details and convert values as needed.
2021-12-17 01:04:54 +00:00
#[ error( " Unsupported config value " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::unsupported_config_value)) ]
2023-12-04 09:19:32 +00:00
UnsupportedConfigValue {
expected : String ,
value : String ,
#[ label( " expected {expected}, got {value} " ) ]
span : Span ,
} ,
2021-12-17 01:04:54 +00:00
2022-04-14 05:08:46 +00:00
/// An expected configuration value is not present.
///
/// ## Resolution
///
/// Refer to the specific error message and add the configuration value to your config file as needed.
2021-12-17 01:04:54 +00:00
#[ error( " Missing config value " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::missing_config_value)) ]
2023-12-04 09:19:32 +00:00
MissingConfigValue {
missing_value : String ,
#[ label( " missing {missing_value} " ) ]
span : Span ,
} ,
2021-12-17 01:04:54 +00:00
Standardise the use of ShellError::UnsupportedInput and ShellError::TypeMismatch and add spans to every instance of the former (#7217)
# Description
* I was dismayed to discover recently that UnsupportedInput and
TypeMismatch are used *extremely* inconsistently across the codebase.
UnsupportedInput is sometimes used for input type-checks (as per the
name!!), but *also* used for argument type-checks. TypeMismatch is also
used for both.
I thus devised the following standard: input type-checking *only* uses
UnsupportedInput, and argument type-checking *only* uses TypeMismatch.
Moreover, to differentiate them, UnsupportedInput now has *two* error
arrows (spans), one pointing at the command and the other at the input
origin, while TypeMismatch only has the one (because the command should
always be nearby)
* In order to apply that standard, a very large number of
UnsupportedInput uses were changed so that the input's span could be
retrieved and delivered to it.
* Additionally, I noticed many places where **errors are not propagated
correctly**: there are lots of `match` sites which take a Value::Error,
then throw it away and replace it with a new Value::Error with
less/misleading information (such as reporting the error as an
"incorrect type"). I believe that the earliest errors are the most
important, and should always be propagated where possible.
* Also, to standardise one broad subset of UnsupportedInput error
messages, who all used slightly different wordings of "expected
`<type>`, got `<type>`", I created OnlySupportsThisInputType as a
variant of it.
* Finally, a bunch of error sites that had "repeated spans" - i.e. where
an error expected two spans, but `call.head` was given for both - were
fixed to use different spans.
# Example
BEFORE
```
〉20b | str starts-with 'a'
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #31:1:1]
1 │ 20b | str starts-with 'a'
· ┬
· ╰── Input's type is filesize. This command only works with strings.
╰────
〉'a' | math cos
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #33:1:1]
1 │ 'a' | math cos
· ─┬─
· ╰── Only numerical values are supported, input type: String
╰────
〉0x[12] | encode utf8
Error: nu::shell::unsupported_input (link)
× Unsupported input
╭─[entry #38:1:1]
1 │ 0x[12] | encode utf8
· ───┬──
· ╰── non-string input
╰────
```
AFTER
```
〉20b | str starts-with 'a'
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #1:1:1]
1 │ 20b | str starts-with 'a'
· ┬ ───────┬───────
· │ ╰── only string input data is supported
· ╰── input type: filesize
╰────
〉'a' | math cos
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #2:1:1]
1 │ 'a' | math cos
· ─┬─ ────┬───
· │ ╰── only numeric input data is supported
· ╰── input type: string
╰────
〉0x[12] | encode utf8
Error: nu::shell::pipeline_mismatch (link)
× Pipeline mismatch.
╭─[entry #3:1:1]
1 │ 0x[12] | encode utf8
· ───┬── ───┬──
· │ ╰── only string input data is supported
· ╰── input type: binary
╰────
```
# User-Facing Changes
Various error messages suddenly make more sense (i.e. have two arrows
instead of one).
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2022-12-23 06:48:53 +00:00
/// Negative value passed when positive one is required.
2022-04-14 05:08:46 +00:00
///
/// ## Resolution
///
/// Guard against negative values or check your inputs.
2022-02-20 20:20:41 +00:00
#[ error( " Negative value passed when positive one is required " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::needs_positive_value)) ]
2023-12-04 09:19:32 +00:00
NeedsPositiveValue {
#[ label( " use a positive value " ) ]
span : Span ,
} ,
2022-02-20 20:20:41 +00:00
2022-04-14 05:08:46 +00:00
/// This is a generic error type used for different situations.
2023-12-06 23:40:03 +00:00
#[ error( " {error} " ) ]
2021-11-28 19:35:02 +00:00
#[ diagnostic() ]
2023-12-06 23:40:03 +00:00
GenericError {
error : String ,
msg : String ,
#[ label( " {msg} " ) ]
span : Option < Span > ,
#[ help ]
help : Option < String > ,
#[ related ]
inner : Vec < ShellError > ,
} ,
2022-02-21 03:31:50 +00:00
2022-04-14 05:08:46 +00:00
/// This is a generic error type used for different situations.
2023-12-10 00:46:21 +00:00
#[ error( " {error} " ) ]
2022-02-21 03:31:50 +00:00
#[ diagnostic() ]
2023-12-10 00:46:21 +00:00
OutsideSpannedLabeledError {
#[ source_code ]
src : String ,
error : String ,
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
2022-02-21 03:31:50 +00:00
2024-03-21 11:27:21 +00:00
/// This is a generic error type used for user and plugin-generated errors.
#[ error(transparent) ]
#[ diagnostic(transparent) ]
LabeledError ( #[ from ] Box < super ::LabeledError > ) ,
2023-08-14 19:17:31 +00:00
/// Attempted to use a command that has been removed from Nushell.
2022-04-14 05:08:46 +00:00
///
/// ## Resolution
///
/// Check the help for the new suggested command and update your script accordingly.
2023-12-10 00:46:21 +00:00
#[ error( " Removed command: {removed} " ) ]
2023-08-14 19:17:31 +00:00
#[ diagnostic(code(nu::shell::removed_command)) ]
2023-12-10 00:46:21 +00:00
RemovedCommand {
removed : String ,
replacement : String ,
#[ label( " '{removed}' has been removed from Nushell. Please use '{replacement}' instead. " ) ]
span : Span ,
} ,
2022-12-10 17:23:24 +00:00
2022-08-28 08:40:14 +00:00
// It should be only used by commands accepts block, and accept inputs from pipeline.
/// Failed to eval block with specific pipeline input.
#[ error( " Eval block failed with pipeline input " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::eval_block_with_input)) ]
2023-12-10 00:46:21 +00:00
EvalBlockWithInput {
#[ label( " source value " ) ]
span : Span ,
#[ related ]
sources : Vec < ShellError > ,
} ,
New commands: `break`, `continue`, `return`, and `loop` (#7230)
# Description
This adds `break`, `continue`, `return`, and `loop`.
* `break` - breaks out a loop
* `continue` - continues a loop at the next iteration
* `return` - early return from a function call
* `loop` - loop forever (until the loop hits a break)
Examples:
```
for i in 1..10 {
if $i == 5 {
continue
}
print $i
}
```
```
for i in 1..10 {
if $i == 5 {
break
}
print $i
}
```
```
def foo [x] {
if true {
return 2
}
$x
}
foo 100
```
```
loop { print "hello, forever" }
```
```
[1, 2, 3, 4, 5] | each {|x|
if $x > 3 { break }
$x
}
```
# User-Facing Changes
Adds the above commands.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2022-11-24 20:39:16 +00:00
/// Break event, which may become an error if used outside of a loop
#[ error( " Break used outside of loop " ) ]
2023-12-10 00:46:21 +00:00
Break {
#[ label( " used outside of loop " ) ]
span : Span ,
} ,
New commands: `break`, `continue`, `return`, and `loop` (#7230)
# Description
This adds `break`, `continue`, `return`, and `loop`.
* `break` - breaks out a loop
* `continue` - continues a loop at the next iteration
* `return` - early return from a function call
* `loop` - loop forever (until the loop hits a break)
Examples:
```
for i in 1..10 {
if $i == 5 {
continue
}
print $i
}
```
```
for i in 1..10 {
if $i == 5 {
break
}
print $i
}
```
```
def foo [x] {
if true {
return 2
}
$x
}
foo 100
```
```
loop { print "hello, forever" }
```
```
[1, 2, 3, 4, 5] | each {|x|
if $x > 3 { break }
$x
}
```
# User-Facing Changes
Adds the above commands.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2022-11-24 20:39:16 +00:00
/// Continue event, which may become an error if used outside of a loop
#[ error( " Continue used outside of loop " ) ]
2023-12-10 00:46:21 +00:00
Continue {
#[ label( " used outside of loop " ) ]
span : Span ,
} ,
New commands: `break`, `continue`, `return`, and `loop` (#7230)
# Description
This adds `break`, `continue`, `return`, and `loop`.
* `break` - breaks out a loop
* `continue` - continues a loop at the next iteration
* `return` - early return from a function call
* `loop` - loop forever (until the loop hits a break)
Examples:
```
for i in 1..10 {
if $i == 5 {
continue
}
print $i
}
```
```
for i in 1..10 {
if $i == 5 {
break
}
print $i
}
```
```
def foo [x] {
if true {
return 2
}
$x
}
foo 100
```
```
loop { print "hello, forever" }
```
```
[1, 2, 3, 4, 5] | each {|x|
if $x > 3 { break }
$x
}
```
# User-Facing Changes
Adds the above commands.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2022-11-24 20:39:16 +00:00
/// Return event, which may become an error if used outside of a function
#[ error( " Return used outside of function " ) ]
2023-12-10 00:46:21 +00:00
Return {
#[ label( " used outside of function " ) ]
span : Span ,
value : Box < Value > ,
} ,
2023-01-05 02:38:50 +00:00
/// The code being executed called itself too many times.
///
/// ## Resolution
///
/// Adjust your Nu code to
#[ error( " Recursion limit ({recursion_limit}) reached " ) ]
2023-02-24 17:26:31 +00:00
#[ diagnostic(code(nu::shell::recursion_limit_reached)) ]
2023-01-05 02:38:50 +00:00
RecursionLimitReached {
recursion_limit : u64 ,
#[ label( " This called itself too many times " ) ]
span : Option < Span > ,
} ,
LazyRecord (#7619)
This is an attempt to implement a new `Value::LazyRecord` variant for
performance reasons.
`LazyRecord` is like a regular `Record`, but it's possible to access
individual columns without evaluating other columns. I've implemented
`LazyRecord` for the special `$nu` variable; accessing `$nu` is
relatively slow because of all the information in `scope`, and [`$nu`
accounts for about 2/3 of Nu's startup time on
Linux](https://github.com/nushell/nushell/issues/6677#issuecomment-1364618122).
### Benchmarks
I ran some benchmarks on my desktop (Linux, 12900K) and the results are
very pleasing.
Nu's time to start up and run a command (`cargo build --release;
hyperfine 'target/release/nu -c "echo \"Hello, world!\""' --shell=none
--warmup 10`) goes from **8.8ms to 3.2ms, about 2.8x faster**.
Tests are also much faster! Running `cargo nextest` (with our very slow
`proptest` tests disabled) goes from **7.2s to 4.4s (1.6x faster)**,
because most tests involve launching a new instance of Nu.
### Design (updated)
I've added a new `LazyRecord` trait and added a `Value` variant wrapping
those trait objects, much like `CustomValue`. `LazyRecord`
implementations must implement these 2 functions:
```rust
// All column names
fn column_names(&self) -> Vec<&'static str>;
// Get 1 specific column value
fn get_column_value(&self, column: &str) -> Result<Value, ShellError>;
```
### Serializability
`Value` variants must implement `Serializable` and `Deserializable`, which poses some problems because I want to use unserializable things like `EngineState` in `LazyRecord`s. To work around this, I basically lie to the type system:
1. Add `#[typetag::serde(tag = "type")]` to `LazyRecord` to make it serializable
2. Any unserializable fields in `LazyRecord` implementations get marked with `#[serde(skip)]`
3. At the point where a `LazyRecord` normally would get serialized and sent to a plugin, I instead collect it into a regular `Value::Record` (which can be serialized)
2023-01-19 03:27:26 +00:00
2024-07-07 22:29:01 +00:00
/// Operation interrupted
#[ error( " Operation interrupted " ) ]
Interrupted {
#[ label( " This operation was interrupted " ) ]
span : Span ,
} ,
2023-03-24 19:45:55 +00:00
/// Operation interrupted by user
#[ error( " Operation interrupted by user " ) ]
InterruptedByUser {
#[ label( " This operation was interrupted " ) ]
span : Option < Span > ,
} ,
2023-07-16 00:25:12 +00:00
/// An attempt to use, as a match guard, an expression that
/// does not resolve into a boolean
#[ error( " Match guard not bool " ) ]
#[ diagnostic(
code ( nu ::shell ::match_guard_not_bool ) ,
help ( " Match guards should evaluate to a boolean " )
) ]
MatchGuardNotBool {
#[ label( " not a boolean expression " ) ]
span : Span ,
} ,
2023-08-26 13:41:29 +00:00
/// An attempt to run a command marked for constant evaluation lacking the const. eval.
/// implementation.
///
/// This is an internal Nushell error, please file an issue.
#[ error( " Missing const eval implementation " ) ]
#[ diagnostic(
code ( nu ::shell ::missing_const_eval_implementation ) ,
help (
" The command lacks an implementation for constant evaluation. \
This is an internal Nushell error , please file an issue https ://github.com/nushell/nushell/issues."
)
) ]
MissingConstEvalImpl {
#[ label( " command lacks constant implementation " ) ]
span : Span ,
} ,
/// Tried assigning non-constant value to a constant
///
/// ## Resolution
///
/// Only a subset of expressions are allowed to be assigned as a constant during parsing.
#[ error( " Not a constant. " ) ]
#[ diagnostic(
code ( nu ::shell ::not_a_constant ) ,
help ( " Only a subset of expressions are allowed constants during parsing. Try using the 'const' command or typing the value literally. " )
) ]
2023-12-10 00:46:21 +00:00
NotAConstant {
#[ label( " Value is not a parse-time constant " ) ]
span : Span ,
} ,
2023-08-26 13:41:29 +00:00
/// Tried running a command that is not const-compatible
///
/// ## Resolution
///
/// Only a subset of builtin commands, and custom commands built only from those commands, can
/// run at parse time.
#[ error( " Not a const command. " ) ]
#[ diagnostic(
code ( nu ::shell ::not_a_const_command ) ,
help ( " Only a subset of builtin commands, and custom commands built only from those commands, can run at parse time. " )
) ]
2023-12-10 00:46:21 +00:00
NotAConstCommand {
#[ label( " This command cannot run at parse time. " ) ]
span : Span ,
} ,
2023-08-26 13:41:29 +00:00
/// Tried getting a help message at parse time.
///
/// ## Resolution
///
/// Help messages are not supported at parse time.
#[ error( " Help message not a constant. " ) ]
#[ diagnostic(
code ( nu ::shell ::not_a_const_help ) ,
help ( " Help messages are currently not supported to be constants. " )
) ]
2023-12-10 00:46:21 +00:00
NotAConstHelp {
#[ label( " This command cannot run at parse time. " ) ]
span : Span ,
} ,
Allow filesystem commands to access files with glob metachars in name (#10694)
(squashed version of #10557, clean commit history and review thread)
Fixes #10571, also potentially: #10364, #10211, #9558, #9310,
# Description
Changes processing of arguments to filesystem commands that are source
paths or globs.
Applies to `cp, cp-old, mv, rm, du` but not `ls` (because it uses a
different globbing interface) or `glob` (because it uses a different
globbing library).
The core of the change is to lookup the argument first as a file and
only glob if it is not. That way,
a path containing glob metacharacters can be referenced without glob
quoting, though it will have to be single quoted to avoid nushell
parsing.
Before: A file path that looks like a glob is not matched by the glob
specified as a (source) argument and takes some thinking about to
access. You might say the glob pattern shadows a file with the same
spelling.
```
> ls a*
╭───┬────────┬──────┬──────┬────────────────╮
│ # │ name │ type │ size │ modified │
├───┼────────┼──────┼──────┼────────────────┤
│ 0 │ a[bc]d │ file │ 0 B │ 34 seconds ago │
│ 1 │ abd │ file │ 0 B │ now │
│ 2 │ acd │ file │ 0 B │ now │
╰───┴────────┴──────┴──────┴────────────────╯
> cp --verbose 'a[bc]d' dest
copied /home/bobhy/src/rust/work/r4/abd to /home/bobhy/src/rust/work/r4/dest/abd
copied /home/bobhy/src/rust/work/r4/acd to /home/bobhy/src/rust/work/r4/dest/acd
> ## Note -- a[bc]d *not* copied, and seemingly hard to access.
> cp --verbose 'a\[bc\]d' dest
Error: × No matches found
╭─[entry #33:1:1]
1 │ cp --verbose 'a\[bc\]d' dest
· ─────┬────
· ╰── no matches found
╰────
> #.. but is accessible with enough glob quoting.
> cp --verbose 'a[[]bc[]]d' dest
copied /home/bobhy/src/rust/work/r4/a[bc]d to /home/bobhy/src/rust/work/r4/dest/a[bc]d
```
Before_2: if file has glob metachars but isn't a valid pattern, user
gets a confusing error:
```
> touch 'a[b'
> cp 'a[b' dest
Error: × Pattern syntax error near position 30: invalid range pattern
╭─[entry #13:1:1]
1 │ cp 'a[b' dest
· ──┬──
· ╰── invalid pattern
╰────
```
After: Args to cp, mv, etc. are tried first as literal files, and only
as globs if not found to be files.
```
> cp --verbose 'a[bc]d' dest
copied /home/bobhy/src/rust/work/r4/a[bc]d to /home/bobhy/src/rust/work/r4/dest/a[bc]d
> cp --verbose '[a][bc]d' dest
copied /home/bobhy/src/rust/work/r4/abd to /home/bobhy/src/rust/work/r4/dest/abd
copied /home/bobhy/src/rust/work/r4/acd to /home/bobhy/src/rust/work/r4/dest/acd
```
After_2: file with glob metachars but invalid pattern just works.
(though Windows does not allow file name to contain `*`.).
```
> cp --verbose 'a[b' dest
copied /home/bobhy/src/rust/work/r4/a[b to /home/bobhy/src/rust/work/r4/dest/a[b
```
So, with this fix, a file shadows a glob pattern with the same spelling.
If you have such a file and really want to use the glob pattern, you
will have to glob quote some of the characters in the pattern. I think
that's less confusing to the user: if ls shows a file with a weird name,
s/he'll still be able to copy, rename or delete it.
# User-Facing Changes
Could break some existing scripts. If user happened to have a file with
a globbish name but was using a glob pattern with the same spelling, the
new version will process the file and not expand the glob.
# 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.
-->
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
2023-10-18 18:31:15 +00:00
/// Invalid glob pattern
///
/// ## Resolution
///
/// Correct glob pattern
#[ error( " Invalid glob pattern " ) ]
#[ diagnostic(
code ( nu ::shell ::invalid_glob_pattern ) ,
help ( " Refer to xxx for help on nushell glob patterns. " )
) ]
2023-12-10 00:46:21 +00:00
InvalidGlobPattern {
msg : String ,
#[ label( " {msg} " ) ]
span : Span ,
} ,
Allow filesystem commands to access files with glob metachars in name (#10694)
(squashed version of #10557, clean commit history and review thread)
Fixes #10571, also potentially: #10364, #10211, #9558, #9310,
# Description
Changes processing of arguments to filesystem commands that are source
paths or globs.
Applies to `cp, cp-old, mv, rm, du` but not `ls` (because it uses a
different globbing interface) or `glob` (because it uses a different
globbing library).
The core of the change is to lookup the argument first as a file and
only glob if it is not. That way,
a path containing glob metacharacters can be referenced without glob
quoting, though it will have to be single quoted to avoid nushell
parsing.
Before: A file path that looks like a glob is not matched by the glob
specified as a (source) argument and takes some thinking about to
access. You might say the glob pattern shadows a file with the same
spelling.
```
> ls a*
╭───┬────────┬──────┬──────┬────────────────╮
│ # │ name │ type │ size │ modified │
├───┼────────┼──────┼──────┼────────────────┤
│ 0 │ a[bc]d │ file │ 0 B │ 34 seconds ago │
│ 1 │ abd │ file │ 0 B │ now │
│ 2 │ acd │ file │ 0 B │ now │
╰───┴────────┴──────┴──────┴────────────────╯
> cp --verbose 'a[bc]d' dest
copied /home/bobhy/src/rust/work/r4/abd to /home/bobhy/src/rust/work/r4/dest/abd
copied /home/bobhy/src/rust/work/r4/acd to /home/bobhy/src/rust/work/r4/dest/acd
> ## Note -- a[bc]d *not* copied, and seemingly hard to access.
> cp --verbose 'a\[bc\]d' dest
Error: × No matches found
╭─[entry #33:1:1]
1 │ cp --verbose 'a\[bc\]d' dest
· ─────┬────
· ╰── no matches found
╰────
> #.. but is accessible with enough glob quoting.
> cp --verbose 'a[[]bc[]]d' dest
copied /home/bobhy/src/rust/work/r4/a[bc]d to /home/bobhy/src/rust/work/r4/dest/a[bc]d
```
Before_2: if file has glob metachars but isn't a valid pattern, user
gets a confusing error:
```
> touch 'a[b'
> cp 'a[b' dest
Error: × Pattern syntax error near position 30: invalid range pattern
╭─[entry #13:1:1]
1 │ cp 'a[b' dest
· ──┬──
· ╰── invalid pattern
╰────
```
After: Args to cp, mv, etc. are tried first as literal files, and only
as globs if not found to be files.
```
> cp --verbose 'a[bc]d' dest
copied /home/bobhy/src/rust/work/r4/a[bc]d to /home/bobhy/src/rust/work/r4/dest/a[bc]d
> cp --verbose '[a][bc]d' dest
copied /home/bobhy/src/rust/work/r4/abd to /home/bobhy/src/rust/work/r4/dest/abd
copied /home/bobhy/src/rust/work/r4/acd to /home/bobhy/src/rust/work/r4/dest/acd
```
After_2: file with glob metachars but invalid pattern just works.
(though Windows does not allow file name to contain `*`.).
```
> cp --verbose 'a[b' dest
copied /home/bobhy/src/rust/work/r4/a[b to /home/bobhy/src/rust/work/r4/dest/a[b
```
So, with this fix, a file shadows a glob pattern with the same spelling.
If you have such a file and really want to use the glob pattern, you
will have to glob quote some of the characters in the pattern. I think
that's less confusing to the user: if ls shows a file with a weird name,
s/he'll still be able to copy, rename or delete it.
# User-Facing Changes
Could break some existing scripts. If user happened to have a file with
a globbish name but was using a glob pattern with the same spelling, the
new version will process the file and not expand the glob.
# 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.
-->
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
2023-10-18 18:31:15 +00:00
Allow spreading arguments to commands (#11289)
<!--
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!
-->
Finishes implementing https://github.com/nushell/nushell/issues/10598,
which asks for a spread operator in lists, in records, and when calling
commands.
# 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 will allow spreading arguments to commands (both internal and
external). It will also deprecate spreading arguments automatically when
passing to external commands.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
- Users will be able to use `...` to spread arguments to custom/builtin
commands that have rest parameters or allow unknown arguments, or to any
external command
- If a custom command doesn't have a rest parameter and it doesn't allow
unknown arguments either, the spread operator will not be allowed
- Passing lists to external commands without `...` will work for now but
will cause a deprecation warning saying that it'll stop working in 0.91
(is 2 versions enough time?)
Here's a function to help with demonstrating some behavior:
```nushell
> def foo [ a, b, c?, d?, ...rest ] { [$a $b $c $d $rest] | to nuon }
```
You can pass a list of arguments to fill in the `rest` parameter using
`...`:
```nushell
> foo 1 2 3 4 ...[5 6]
[1, 2, 3, 4, [5, 6]]
```
If you don't use `...`, the list `[5 6]` will be treated as a single
argument:
```nushell
> foo 1 2 3 4 [5 6] # Note the double [[]]
[1, 2, 3, 4, [[5, 6]]]
```
You can omit optional parameters before the spread arguments:
```nushell
> foo 1 2 3 ...[4 5] # d is omitted here
[1, 2, 3, null, [4, 5]]
```
If you have multiple lists, you can spread them all:
```nushell
> foo 1 2 3 ...[4 5] 6 7 ...[8] ...[]
[1, 2, 3, null, [4, 5, 6, 7, 8]]
```
Here's the kind of error you get when you try to spread arguments to a
command with no rest parameter:
And this is the warning you get when you pass a list to an external now
(without `...`):
# 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 tests to cover the following cases:
- Spreading arguments to a command that doesn't have a rest parameter
(unexpected spread argument error)
- Spreading arguments to a command that doesn't have a rest parameter
*but* there's also a missing positional argument (missing positional
error)
- Spreading arguments to a command that doesn't have a rest parameter
but does allow unknown arguments, such as `exec` (allowed)
- Spreading a list literal containing arguments of the wrong type (parse
error)
- Spreading a non-list value, both to internal and external commands
- Having named arguments in the middle of rest arguments
- `explain`ing a command call that spreads its arguments
# 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.
-->
# Examples
Suppose you have multiple tables:
```nushell
let people = [[id name age]; [0 alice 100] [1 bob 200] [2 eve 300]]
let evil_twins = [[id name age]; [0 ecila 100] [-1 bob 200] [-2 eve 300]]
```
Maybe you often find yourself needing to merge multiple tables and want
a utility to do that. You could write a function like this:
```nushell
def merge_all [ ...tables ] { $tables | reduce { |it, acc| $acc | merge $it } }
```
Then you can use it like this:
```nushell
> merge_all ...([$people $evil_twins] | each { |$it| $it | select name age })
╭───┬───────┬─────╮
│ # │ name │ age │
├───┼───────┼─────┤
│ 0 │ ecila │ 100 │
│ 1 │ bob │ 200 │
│ 2 │ eve │ 300 │
╰───┴───────┴─────╯
```
Except they had duplicate columns, so now you first want to suffix every
column with a number to tell you which table the column came from. You
can make a command for that:
```nushell
def select_and_merge [ --cols: list<string>, ...tables ] {
let renamed_tables = $tables
| enumerate
| each { |it|
$it.item | select $cols | rename ...($cols | each { |col| $col + ($it.index | into string) })
};
merge_all ...$renamed_tables
}
```
And call it like this:
```nushell
> select_and_merge --cols [name age] $people $evil_twins
╭───┬───────┬──────┬───────┬──────╮
│ # │ name0 │ age0 │ name1 │ age1 │
├───┼───────┼──────┼───────┼──────┤
│ 0 │ alice │ 100 │ ecila │ 100 │
│ 1 │ bob │ 200 │ bob │ 200 │
│ 2 │ eve │ 300 │ eve │ 300 │
╰───┴───────┴──────┴───────┴──────╯
```
---
Suppose someone's made a command to search for APT packages:
```nushell
# The main command
def search-pkgs [
--install # Whether to install any packages it finds
log_level: int # Pretend it's a good idea to make this a required positional parameter
exclude?: list<string> # Packages to exclude
repositories?: list<string> # Which repositories to look in (searches in all if not given)
...pkgs # Package names to search for
] {
{ install: $install, log_level: $log_level, exclude: ($exclude | to nuon), repositories: ($repositories | to nuon), pkgs: ($pkgs | to nuon) }
}
```
It has a lot of parameters to configure it, so you might make your own
helper commands to wrap around it for specific cases. Here's one
example:
```nushell
# Only look for packages locally
def search-pkgs-local [
--install # Whether to install any packages it finds
log_level: int
exclude?: list<string> # Packages to exclude
...pkgs # Package names to search for
] {
# All required and optional positional parameters are given
search-pkgs --install=$install $log_level [] ["<local URI or something>"] ...$pkgs
}
```
And you can run it like this:
```nushell
> search-pkgs-local --install=false 5 ...["python2.7" "vim"]
╭──────────────┬──────────────────────────────╮
│ install │ false │
│ log_level │ 5 │
│ exclude │ [] │
│ repositories │ ["<local URI or something>"] │
│ pkgs │ ["python2.7", vim] │
╰──────────────┴──────────────────────────────╯
```
One thing I realized when writing this was that if we decide to not
allow passing optional arguments using the spread operator, then you can
(mis?)use the spread operator to skip optional parameters. Here, I
didn't want to give `exclude` explicitly, so I used a spread operator to
pass the packages to install. Without it, I would've needed to do
`search-pkgs-local --install=false 5 [] "python2.7" "vim"` (explicitly
pass `[]` (or `null`, in the general case) to `exclude`). There are
probably more idiomatic ways to do this, but I just thought it was
something interesting.
If you're a virologist of the [xkcd](https://xkcd.com/350/) kind,
another helper command you might make is this:
```nushell
# Install any packages it finds
def live-dangerously [ ...pkgs ] {
# One optional argument was given (exclude), while another was not (repositories)
search-pkgs 0 [] ...$pkgs --install # Flags can go after spread arguments
}
```
Running it:
```nushell
> live-dangerously "git" "*vi*" # *vi* because I don't feel like typing out vim and neovim
╭──────────────┬─────────────╮
│ install │ true │
│ log_level │ 0 │
│ exclude │ [] │
│ repositories │ null │
│ pkgs │ [git, *vi*] │
╰──────────────┴─────────────╯
```
Here's an example that uses the spread operator more than once within
the same command call:
```nushell
let extras = [ chrome firefox python java git ]
def search-pkgs-curated [ ...pkgs ] {
(search-pkgs
1
[emacs]
["example.com", "foo.com"]
vim # A must for everyone!
...($pkgs | filter { |p| not ($p | str contains "*") }) # Remove packages with globs
python # Good tool to have
...$extras
--install=false
python3) # I forget, did I already put Python in extras?
}
```
Running it:
```nushell
> search-pkgs-curated "git" "*vi*"
╭──────────────┬───────────────────────────────────────────────────────────────────╮
│ install │ false │
│ log_level │ 1 │
│ exclude │ [emacs] │
│ repositories │ [example.com, foo.com] │
│ pkgs │ [vim, git, python, chrome, firefox, python, java, git, "python3"] │
╰──────────────┴───────────────────────────────────────────────────────────────────╯
```
2023-12-28 07:43:20 +00:00
/// Tried spreading a non-list inside a list or command call.
2023-11-22 21:10:08 +00:00
///
/// ## Resolution
///
Allow spreading arguments to commands (#11289)
<!--
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!
-->
Finishes implementing https://github.com/nushell/nushell/issues/10598,
which asks for a spread operator in lists, in records, and when calling
commands.
# 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 will allow spreading arguments to commands (both internal and
external). It will also deprecate spreading arguments automatically when
passing to external commands.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
- Users will be able to use `...` to spread arguments to custom/builtin
commands that have rest parameters or allow unknown arguments, or to any
external command
- If a custom command doesn't have a rest parameter and it doesn't allow
unknown arguments either, the spread operator will not be allowed
- Passing lists to external commands without `...` will work for now but
will cause a deprecation warning saying that it'll stop working in 0.91
(is 2 versions enough time?)
Here's a function to help with demonstrating some behavior:
```nushell
> def foo [ a, b, c?, d?, ...rest ] { [$a $b $c $d $rest] | to nuon }
```
You can pass a list of arguments to fill in the `rest` parameter using
`...`:
```nushell
> foo 1 2 3 4 ...[5 6]
[1, 2, 3, 4, [5, 6]]
```
If you don't use `...`, the list `[5 6]` will be treated as a single
argument:
```nushell
> foo 1 2 3 4 [5 6] # Note the double [[]]
[1, 2, 3, 4, [[5, 6]]]
```
You can omit optional parameters before the spread arguments:
```nushell
> foo 1 2 3 ...[4 5] # d is omitted here
[1, 2, 3, null, [4, 5]]
```
If you have multiple lists, you can spread them all:
```nushell
> foo 1 2 3 ...[4 5] 6 7 ...[8] ...[]
[1, 2, 3, null, [4, 5, 6, 7, 8]]
```
Here's the kind of error you get when you try to spread arguments to a
command with no rest parameter:
And this is the warning you get when you pass a list to an external now
(without `...`):
# 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 tests to cover the following cases:
- Spreading arguments to a command that doesn't have a rest parameter
(unexpected spread argument error)
- Spreading arguments to a command that doesn't have a rest parameter
*but* there's also a missing positional argument (missing positional
error)
- Spreading arguments to a command that doesn't have a rest parameter
but does allow unknown arguments, such as `exec` (allowed)
- Spreading a list literal containing arguments of the wrong type (parse
error)
- Spreading a non-list value, both to internal and external commands
- Having named arguments in the middle of rest arguments
- `explain`ing a command call that spreads its arguments
# 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.
-->
# Examples
Suppose you have multiple tables:
```nushell
let people = [[id name age]; [0 alice 100] [1 bob 200] [2 eve 300]]
let evil_twins = [[id name age]; [0 ecila 100] [-1 bob 200] [-2 eve 300]]
```
Maybe you often find yourself needing to merge multiple tables and want
a utility to do that. You could write a function like this:
```nushell
def merge_all [ ...tables ] { $tables | reduce { |it, acc| $acc | merge $it } }
```
Then you can use it like this:
```nushell
> merge_all ...([$people $evil_twins] | each { |$it| $it | select name age })
╭───┬───────┬─────╮
│ # │ name │ age │
├───┼───────┼─────┤
│ 0 │ ecila │ 100 │
│ 1 │ bob │ 200 │
│ 2 │ eve │ 300 │
╰───┴───────┴─────╯
```
Except they had duplicate columns, so now you first want to suffix every
column with a number to tell you which table the column came from. You
can make a command for that:
```nushell
def select_and_merge [ --cols: list<string>, ...tables ] {
let renamed_tables = $tables
| enumerate
| each { |it|
$it.item | select $cols | rename ...($cols | each { |col| $col + ($it.index | into string) })
};
merge_all ...$renamed_tables
}
```
And call it like this:
```nushell
> select_and_merge --cols [name age] $people $evil_twins
╭───┬───────┬──────┬───────┬──────╮
│ # │ name0 │ age0 │ name1 │ age1 │
├───┼───────┼──────┼───────┼──────┤
│ 0 │ alice │ 100 │ ecila │ 100 │
│ 1 │ bob │ 200 │ bob │ 200 │
│ 2 │ eve │ 300 │ eve │ 300 │
╰───┴───────┴──────┴───────┴──────╯
```
---
Suppose someone's made a command to search for APT packages:
```nushell
# The main command
def search-pkgs [
--install # Whether to install any packages it finds
log_level: int # Pretend it's a good idea to make this a required positional parameter
exclude?: list<string> # Packages to exclude
repositories?: list<string> # Which repositories to look in (searches in all if not given)
...pkgs # Package names to search for
] {
{ install: $install, log_level: $log_level, exclude: ($exclude | to nuon), repositories: ($repositories | to nuon), pkgs: ($pkgs | to nuon) }
}
```
It has a lot of parameters to configure it, so you might make your own
helper commands to wrap around it for specific cases. Here's one
example:
```nushell
# Only look for packages locally
def search-pkgs-local [
--install # Whether to install any packages it finds
log_level: int
exclude?: list<string> # Packages to exclude
...pkgs # Package names to search for
] {
# All required and optional positional parameters are given
search-pkgs --install=$install $log_level [] ["<local URI or something>"] ...$pkgs
}
```
And you can run it like this:
```nushell
> search-pkgs-local --install=false 5 ...["python2.7" "vim"]
╭──────────────┬──────────────────────────────╮
│ install │ false │
│ log_level │ 5 │
│ exclude │ [] │
│ repositories │ ["<local URI or something>"] │
│ pkgs │ ["python2.7", vim] │
╰──────────────┴──────────────────────────────╯
```
One thing I realized when writing this was that if we decide to not
allow passing optional arguments using the spread operator, then you can
(mis?)use the spread operator to skip optional parameters. Here, I
didn't want to give `exclude` explicitly, so I used a spread operator to
pass the packages to install. Without it, I would've needed to do
`search-pkgs-local --install=false 5 [] "python2.7" "vim"` (explicitly
pass `[]` (or `null`, in the general case) to `exclude`). There are
probably more idiomatic ways to do this, but I just thought it was
something interesting.
If you're a virologist of the [xkcd](https://xkcd.com/350/) kind,
another helper command you might make is this:
```nushell
# Install any packages it finds
def live-dangerously [ ...pkgs ] {
# One optional argument was given (exclude), while another was not (repositories)
search-pkgs 0 [] ...$pkgs --install # Flags can go after spread arguments
}
```
Running it:
```nushell
> live-dangerously "git" "*vi*" # *vi* because I don't feel like typing out vim and neovim
╭──────────────┬─────────────╮
│ install │ true │
│ log_level │ 0 │
│ exclude │ [] │
│ repositories │ null │
│ pkgs │ [git, *vi*] │
╰──────────────┴─────────────╯
```
Here's an example that uses the spread operator more than once within
the same command call:
```nushell
let extras = [ chrome firefox python java git ]
def search-pkgs-curated [ ...pkgs ] {
(search-pkgs
1
[emacs]
["example.com", "foo.com"]
vim # A must for everyone!
...($pkgs | filter { |p| not ($p | str contains "*") }) # Remove packages with globs
python # Good tool to have
...$extras
--install=false
python3) # I forget, did I already put Python in extras?
}
```
Running it:
```nushell
> search-pkgs-curated "git" "*vi*"
╭──────────────┬───────────────────────────────────────────────────────────────────╮
│ install │ false │
│ log_level │ 1 │
│ exclude │ [emacs] │
│ repositories │ [example.com, foo.com] │
│ pkgs │ [vim, git, python, chrome, firefox, python, java, git, "python3"] │
╰──────────────┴───────────────────────────────────────────────────────────────────╯
```
2023-12-28 07:43:20 +00:00
/// Only lists can be spread inside lists and command calls. Try converting the value to a list before spreading.
2023-11-22 21:10:08 +00:00
#[ error( " Not a list " ) ]
#[ diagnostic(
Spread operator in record literals (#11144)
Goes towards implementing #10598, which asks for a spread operator in
lists, in records, and when calling commands (continuation of #11006,
which only implements it in lists)
# Description
This PR is for adding a spread operator that can be used when building
records. Additional functionality can be added later.
Changes:
- Previously, the `Expr::Record` variant held `(Expression, Expression)`
pairs. It now holds instances of an enum `RecordItem` (the name isn't
amazing) that allows either a key-value mapping or a spread operator.
- `...` will be treated as the spread operator when it appears before
`$`, `{`, or `(` inside records (no whitespace allowed in between) (not
implemented yet)
- The error message for duplicate columns now includes the column name
itself, because if two spread records are involved in such an error, you
can't tell which field was duplicated from the spans alone
`...` will still be treated as a normal string outside records, and even
in records, it is not treated as a spread operator when not followed
immediately by a `$`, `{`, or `(`.
# User-Facing Changes
Users will be able to use `...` when building records.
```
> let rec = { x: 1, ...{ a: 2 } }
> $rec
╭───┬───╮
│ x │ 1 │
│ a │ 2 │
╰───┴───╯
> { foo: bar, ...$rec, baz: blah }
╭─────┬──────╮
│ foo │ bar │
│ x │ 1 │
│ a │ 2 │
│ baz │ blah │
╰─────┴──────╯
```
If you want to update a field of a record, you'll have to use `merge`
instead:
```
> { ...$rec, x: 5 }
Error: nu::shell::column_defined_twice
× Record field or table column used twice: x
╭─[entry #2:1:1]
1 │ { ...$rec, x: 5 }
· ──┬─ ┬
· │ ╰── field redefined here
· ╰── field first defined here
╰────
> $rec | merge { x: 5 }
╭───┬───╮
│ x │ 5 │
│ a │ 2 │
╰───┴───╯
```
# Tests + Formatting
# After Submitting
2023-11-29 17:31:31 +00:00
code ( nu ::shell ::cannot_spread_as_list ) ,
Allow spreading arguments to commands (#11289)
<!--
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!
-->
Finishes implementing https://github.com/nushell/nushell/issues/10598,
which asks for a spread operator in lists, in records, and when calling
commands.
# 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 will allow spreading arguments to commands (both internal and
external). It will also deprecate spreading arguments automatically when
passing to external commands.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
- Users will be able to use `...` to spread arguments to custom/builtin
commands that have rest parameters or allow unknown arguments, or to any
external command
- If a custom command doesn't have a rest parameter and it doesn't allow
unknown arguments either, the spread operator will not be allowed
- Passing lists to external commands without `...` will work for now but
will cause a deprecation warning saying that it'll stop working in 0.91
(is 2 versions enough time?)
Here's a function to help with demonstrating some behavior:
```nushell
> def foo [ a, b, c?, d?, ...rest ] { [$a $b $c $d $rest] | to nuon }
```
You can pass a list of arguments to fill in the `rest` parameter using
`...`:
```nushell
> foo 1 2 3 4 ...[5 6]
[1, 2, 3, 4, [5, 6]]
```
If you don't use `...`, the list `[5 6]` will be treated as a single
argument:
```nushell
> foo 1 2 3 4 [5 6] # Note the double [[]]
[1, 2, 3, 4, [[5, 6]]]
```
You can omit optional parameters before the spread arguments:
```nushell
> foo 1 2 3 ...[4 5] # d is omitted here
[1, 2, 3, null, [4, 5]]
```
If you have multiple lists, you can spread them all:
```nushell
> foo 1 2 3 ...[4 5] 6 7 ...[8] ...[]
[1, 2, 3, null, [4, 5, 6, 7, 8]]
```
Here's the kind of error you get when you try to spread arguments to a
command with no rest parameter:
And this is the warning you get when you pass a list to an external now
(without `...`):
# 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 tests to cover the following cases:
- Spreading arguments to a command that doesn't have a rest parameter
(unexpected spread argument error)
- Spreading arguments to a command that doesn't have a rest parameter
*but* there's also a missing positional argument (missing positional
error)
- Spreading arguments to a command that doesn't have a rest parameter
but does allow unknown arguments, such as `exec` (allowed)
- Spreading a list literal containing arguments of the wrong type (parse
error)
- Spreading a non-list value, both to internal and external commands
- Having named arguments in the middle of rest arguments
- `explain`ing a command call that spreads its arguments
# 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.
-->
# Examples
Suppose you have multiple tables:
```nushell
let people = [[id name age]; [0 alice 100] [1 bob 200] [2 eve 300]]
let evil_twins = [[id name age]; [0 ecila 100] [-1 bob 200] [-2 eve 300]]
```
Maybe you often find yourself needing to merge multiple tables and want
a utility to do that. You could write a function like this:
```nushell
def merge_all [ ...tables ] { $tables | reduce { |it, acc| $acc | merge $it } }
```
Then you can use it like this:
```nushell
> merge_all ...([$people $evil_twins] | each { |$it| $it | select name age })
╭───┬───────┬─────╮
│ # │ name │ age │
├───┼───────┼─────┤
│ 0 │ ecila │ 100 │
│ 1 │ bob │ 200 │
│ 2 │ eve │ 300 │
╰───┴───────┴─────╯
```
Except they had duplicate columns, so now you first want to suffix every
column with a number to tell you which table the column came from. You
can make a command for that:
```nushell
def select_and_merge [ --cols: list<string>, ...tables ] {
let renamed_tables = $tables
| enumerate
| each { |it|
$it.item | select $cols | rename ...($cols | each { |col| $col + ($it.index | into string) })
};
merge_all ...$renamed_tables
}
```
And call it like this:
```nushell
> select_and_merge --cols [name age] $people $evil_twins
╭───┬───────┬──────┬───────┬──────╮
│ # │ name0 │ age0 │ name1 │ age1 │
├───┼───────┼──────┼───────┼──────┤
│ 0 │ alice │ 100 │ ecila │ 100 │
│ 1 │ bob │ 200 │ bob │ 200 │
│ 2 │ eve │ 300 │ eve │ 300 │
╰───┴───────┴──────┴───────┴──────╯
```
---
Suppose someone's made a command to search for APT packages:
```nushell
# The main command
def search-pkgs [
--install # Whether to install any packages it finds
log_level: int # Pretend it's a good idea to make this a required positional parameter
exclude?: list<string> # Packages to exclude
repositories?: list<string> # Which repositories to look in (searches in all if not given)
...pkgs # Package names to search for
] {
{ install: $install, log_level: $log_level, exclude: ($exclude | to nuon), repositories: ($repositories | to nuon), pkgs: ($pkgs | to nuon) }
}
```
It has a lot of parameters to configure it, so you might make your own
helper commands to wrap around it for specific cases. Here's one
example:
```nushell
# Only look for packages locally
def search-pkgs-local [
--install # Whether to install any packages it finds
log_level: int
exclude?: list<string> # Packages to exclude
...pkgs # Package names to search for
] {
# All required and optional positional parameters are given
search-pkgs --install=$install $log_level [] ["<local URI or something>"] ...$pkgs
}
```
And you can run it like this:
```nushell
> search-pkgs-local --install=false 5 ...["python2.7" "vim"]
╭──────────────┬──────────────────────────────╮
│ install │ false │
│ log_level │ 5 │
│ exclude │ [] │
│ repositories │ ["<local URI or something>"] │
│ pkgs │ ["python2.7", vim] │
╰──────────────┴──────────────────────────────╯
```
One thing I realized when writing this was that if we decide to not
allow passing optional arguments using the spread operator, then you can
(mis?)use the spread operator to skip optional parameters. Here, I
didn't want to give `exclude` explicitly, so I used a spread operator to
pass the packages to install. Without it, I would've needed to do
`search-pkgs-local --install=false 5 [] "python2.7" "vim"` (explicitly
pass `[]` (or `null`, in the general case) to `exclude`). There are
probably more idiomatic ways to do this, but I just thought it was
something interesting.
If you're a virologist of the [xkcd](https://xkcd.com/350/) kind,
another helper command you might make is this:
```nushell
# Install any packages it finds
def live-dangerously [ ...pkgs ] {
# One optional argument was given (exclude), while another was not (repositories)
search-pkgs 0 [] ...$pkgs --install # Flags can go after spread arguments
}
```
Running it:
```nushell
> live-dangerously "git" "*vi*" # *vi* because I don't feel like typing out vim and neovim
╭──────────────┬─────────────╮
│ install │ true │
│ log_level │ 0 │
│ exclude │ [] │
│ repositories │ null │
│ pkgs │ [git, *vi*] │
╰──────────────┴─────────────╯
```
Here's an example that uses the spread operator more than once within
the same command call:
```nushell
let extras = [ chrome firefox python java git ]
def search-pkgs-curated [ ...pkgs ] {
(search-pkgs
1
[emacs]
["example.com", "foo.com"]
vim # A must for everyone!
...($pkgs | filter { |p| not ($p | str contains "*") }) # Remove packages with globs
python # Good tool to have
...$extras
--install=false
python3) # I forget, did I already put Python in extras?
}
```
Running it:
```nushell
> search-pkgs-curated "git" "*vi*"
╭──────────────┬───────────────────────────────────────────────────────────────────╮
│ install │ false │
│ log_level │ 1 │
│ exclude │ [emacs] │
│ repositories │ [example.com, foo.com] │
│ pkgs │ [vim, git, python, chrome, firefox, python, java, git, "python3"] │
╰──────────────┴───────────────────────────────────────────────────────────────────╯
```
2023-12-28 07:43:20 +00:00
help ( " Only lists can be spread inside lists and command calls. Try converting the value to a list before spreading. " )
2023-11-22 21:10:08 +00:00
) ]
CannotSpreadAsList {
#[ label = " cannot spread value " ]
span : Span ,
} ,
Spread operator in record literals (#11144)
Goes towards implementing #10598, which asks for a spread operator in
lists, in records, and when calling commands (continuation of #11006,
which only implements it in lists)
# Description
This PR is for adding a spread operator that can be used when building
records. Additional functionality can be added later.
Changes:
- Previously, the `Expr::Record` variant held `(Expression, Expression)`
pairs. It now holds instances of an enum `RecordItem` (the name isn't
amazing) that allows either a key-value mapping or a spread operator.
- `...` will be treated as the spread operator when it appears before
`$`, `{`, or `(` inside records (no whitespace allowed in between) (not
implemented yet)
- The error message for duplicate columns now includes the column name
itself, because if two spread records are involved in such an error, you
can't tell which field was duplicated from the spans alone
`...` will still be treated as a normal string outside records, and even
in records, it is not treated as a spread operator when not followed
immediately by a `$`, `{`, or `(`.
# User-Facing Changes
Users will be able to use `...` when building records.
```
> let rec = { x: 1, ...{ a: 2 } }
> $rec
╭───┬───╮
│ x │ 1 │
│ a │ 2 │
╰───┴───╯
> { foo: bar, ...$rec, baz: blah }
╭─────┬──────╮
│ foo │ bar │
│ x │ 1 │
│ a │ 2 │
│ baz │ blah │
╰─────┴──────╯
```
If you want to update a field of a record, you'll have to use `merge`
instead:
```
> { ...$rec, x: 5 }
Error: nu::shell::column_defined_twice
× Record field or table column used twice: x
╭─[entry #2:1:1]
1 │ { ...$rec, x: 5 }
· ──┬─ ┬
· │ ╰── field redefined here
· ╰── field first defined here
╰────
> $rec | merge { x: 5 }
╭───┬───╮
│ x │ 5 │
│ a │ 2 │
╰───┴───╯
```
# Tests + Formatting
# After Submitting
2023-11-29 17:31:31 +00:00
/// Tried spreading a non-record inside a record.
///
/// ## Resolution
///
/// Only records can be spread inside records. Try converting the value to a record before spreading.
#[ error( " Not a record " ) ]
#[ diagnostic(
code ( nu ::shell ::cannot_spread_as_record ) ,
help ( " Only records can be spread inside records. Try converting the value to a record before spreading. " )
) ]
CannotSpreadAsRecord {
#[ label = " cannot spread value " ]
span : Span ,
} ,
2023-12-01 14:56:06 +00:00
Disallow spreading lists automatically when calling externals (#11857)
<!--
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.
-->
Spreading lists automatically when calling externals was deprecated in
0.89 (#11289), and this PR is to remove it in 0.91.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
The new error message looks like this:
```
> ^echo [1 2]
Error: nu::shell::cannot_pass_list_to_external
× Lists are not automatically spread when calling external commands
╭─[entry #13:1:8]
1 │ ^echo [1 2]
· ──┬──
· ╰── Spread operator (...) is necessary to spread lists
╰────
help: Either convert the list to a string or use the spread operator, like so: ...[1 2]
```
The old error message didn't say exactly where to put the `...` and
seemed to confuse a lot of people, so hopefully this helps.
# 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
> ```
-->
There was one test to check that implicit spread was deprecated before,
updated that to check that it's disallowed now.
# 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.
-->
2024-02-14 23:16:19 +00:00
/// Lists are not automatically spread when calling external commands
///
/// ## Resolution
///
/// Use the spread operator (put a '...' before the argument)
#[ error( " Lists are not automatically spread when calling external commands " ) ]
#[ diagnostic(
code ( nu ::shell ::cannot_pass_list_to_external ) ,
help ( " Either convert the list to a string or use the spread operator, like so: ...{arg} " )
) ]
CannotPassListToExternal {
arg : String ,
#[ label = " Spread operator (...) is necessary to spread lists " ]
span : Span ,
} ,
2023-12-01 14:56:06 +00:00
/// Out of bounds.
///
/// ## Resolution
///
/// Make sure the range is within the bounds of the input.
#[ error(
" The selected range {left_flank}..{right_flank} is out of the bounds of the provided input "
) ]
#[ diagnostic(code(nu::shell::out_of_bounds)) ]
OutOfBounds {
left_flank : String ,
right_flank : String ,
#[ label = " byte index is not a char boundary or is out of bounds of the input " ]
span : Span ,
} ,
Add ConfigDirNotFound error (#11849)
<!--
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.
-->
Currently, there's multiple places that look for a config directory, and
each of them has different error messages when it can't be found. This
PR makes a `ConfigDirNotFound` error to standardize the error message
for all of these cases.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Previously, the errors in `create_nu_constant()` would say which config
file Nushell was trying to get when it couldn't find the config
directory. Now it doesn't. However, I think that's fine, given that it
doesn't matter whether it couldn't find the config directory while
looking for `login.nu` or `env.nu`, it only matters that it couldn't
find it.
This is what the error looks like:
# 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.
-->
---------
Co-authored-by: Antoine Stevan <44101798+amtoine@users.noreply.github.com>
2024-02-26 07:42:20 +00:00
/// The config directory could not be found
#[ error( " The config directory could not be found " ) ]
#[ diagnostic(
code ( nu ::shell ::config_dir_not_found ) ,
help (
r #" On Linux, this would be $XDG_CONFIG_HOME or $HOME/.config.
On MacOS , this would be ` $HOME / Library / Application Support ` .
On Windows , this would be % USERPROFILE % \ AppData \ Roaming " #
)
) ]
ConfigDirNotFound {
#[ label = " Could not find config directory " ]
span : Option < Span > ,
} ,
Use XDG_CONFIG_HOME before default config directory (#12118)
<!--
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!
-->
Closes #12103
# 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.
-->
As described in #12103, this PR makes Nushell use `XDG_CONFIG_HOME` as
the config directory if it exists. Otherwise, it uses the old behavior,
which was to use `dirs_next::config_dir()`.
Edit: We discussed choosing between `XDG_CONFIG_HOME` and the default
config directory in Discord and decided against it, at least for now.
<s>@kubouch also suggested letting users choose between
`XDG_CONFIG_HOME` and the default config directory if config files
aren't found on startup and `XDG_CONFIG_HOME` is set to a value
different from the default config directory</s>
On Windows and MacOS, if the `XDG_CONFIG_HOME` variable is set but
`XDG_CONFIG_HOME` is either empty or doesn't exist *and* the old config
directory is non-empty, Nushell will issue a warning on startup saying
that it won't move files from the old config directory to the new one.
To do this, I had to add a `nu_path::config_dir_old()` function. I
assume that at some point, we will remove the warning message and the
function can be removed too. Alternatively, instead of having that
function there, `main.rs` could directly call `dirs_next::config_dir()`.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
When `$env.XDG_CONFIG_HOME` is set to an absolute path, Nushell will use
`$"($env.XDG_CONFIG_HOME)/nushell"` as its config directory (previously,
this only worked on Linux).
To use `App Data\Roaming` (Windows) or `Library/Application Support`
(MacOS) instead (the old behavior), one can either leave
`XDG_CONFIG_HOME` unset or set it to an empty string.
If `XDG_CONFIG_HOME` is set, but to a non-absolute/invalid path, Nushell
will report an error on startup and use the default config directory
instead:
On Windows and MacOS, if the `XDG_CONFIG_HOME` variable is set but
`XDG_CONFIG_HOME` is either empty or doesn't exist *and* the old config
directory is non-empty, Nushell will issue a warning on startup saying
that it won't move files from the old config directory to the new one.
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` 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
> ```
-->
The existing config path tests have been modified to use
`XDG_CONFIG_HOME` to change the config directory on all OSes, not just
Linux.
# 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.
-->
The documentation will have to be updated to note that Nushell uses
`XDG_CONFIG_HOME` now. As @fdncred pointed out, it's possible for people
to set `XDG_CONFIG_HOME` to, say, `~/.config/nushell` rather than
`~/.config`, so the documentation could warn about that mistake.
2024-03-11 11:15:46 +00:00
/// XDG_CONFIG_HOME was set to an invalid path
#[ error( " $env.XDG_CONFIG_HOME ({xdg}) is invalid, using default config directory instead: {default} " ) ]
#[ diagnostic(
code ( nu ::shell ::xdg_config_home_invalid ) ,
help ( " Set XDG_CONFIG_HOME to an absolute path, or set it to an empty string to ignore it " )
) ]
InvalidXdgConfig { xdg : String , default : String } ,
2023-08-26 13:41:29 +00:00
}
// TODO: Implement as From trait
impl ShellError {
pub fn wrap ( self , working_set : & StateWorkingSet , span : Span ) -> ParseError {
let msg = format_error ( working_set , & self ) ;
ParseError ::LabeledError (
msg ,
" Encountered error during parse-time evaluation " . into ( ) ,
span ,
)
}
2021-10-05 19:54:30 +00:00
}
Replace `ExternalStream` with new `ByteStream` type (#12774)
# Description
This PR introduces a `ByteStream` type which is a `Read`-able stream of
bytes. Internally, it has an enum over three different byte stream
sources:
```rust
pub enum ByteStreamSource {
Read(Box<dyn Read + Send + 'static>),
File(File),
Child(ChildProcess),
}
```
This is in comparison to the current `RawStream` type, which is an
`Iterator<Item = Vec<u8>>` and has to allocate for each read chunk.
Currently, `PipelineData::ExternalStream` serves a weird dual role where
it is either external command output or a wrapper around `RawStream`.
`ByteStream` makes this distinction more clear (via `ByteStreamSource`)
and replaces `PipelineData::ExternalStream` in this PR:
```rust
pub enum PipelineData {
Empty,
Value(Value, Option<PipelineMetadata>),
ListStream(ListStream, Option<PipelineMetadata>),
ByteStream(ByteStream, Option<PipelineMetadata>),
}
```
The PR is relatively large, but a decent amount of it is just repetitive
changes.
This PR fixes #7017, fixes #10763, and fixes #12369.
This PR also improves performance when piping external commands. Nushell
should, in most cases, have competitive pipeline throughput compared to,
e.g., bash.
| Command | Before (MB/s) | After (MB/s) | Bash (MB/s) |
| -------------------------------------------------- | -------------:|
------------:| -----------:|
| `throughput \| rg 'x'` | 3059 | 3744 | 3739 |
| `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 |
# User-Facing Changes
- This is a breaking change for the plugin communication protocol,
because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`.
Plugins now only have to deal with a single input stream, as opposed to
the previous three streams: stdout, stderr, and exit code.
- The output of `describe` has been changed for external/byte streams.
- Temporary breaking change: `bytes starts-with` no longer works with
byte streams. This is to keep the PR smaller, and `bytes ends-with`
already does not work on byte streams.
- If a process core dumped, then instead of having a `Value::Error` in
the `exit_code` column of the output returned from `complete`, it now is
a `Value::Int` with the negation of the signal number.
# After Submitting
- Update docs and book as necessary
- Release notes (e.g., plugin protocol changes)
- Adapt/convert commands to work with byte streams (high priority is
`str length`, `bytes starts-with`, and maybe `bytes ends-with`).
- Refactor the `tee` code, Devyn has already done some work on this.
---------
Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 14:11:18 +00:00
impl From < io ::Error > for ShellError {
fn from ( error : io ::Error ) -> ShellError {
if error . kind ( ) = = io ::ErrorKind ::Other {
match error . into_inner ( ) {
Some ( err ) = > match err . downcast ( ) {
Ok ( err ) = > * err ,
Err ( err ) = > Self ::IOError {
msg : err . to_string ( ) ,
} ,
} ,
None = > Self ::IOError {
msg : " unknown error " . into ( ) ,
} ,
}
} else {
Self ::IOError {
msg : error . to_string ( ) ,
}
2023-11-28 12:43:51 +00:00
}
2021-10-05 19:54:30 +00:00
}
}
Replace `ExternalStream` with new `ByteStream` type (#12774)
# Description
This PR introduces a `ByteStream` type which is a `Read`-able stream of
bytes. Internally, it has an enum over three different byte stream
sources:
```rust
pub enum ByteStreamSource {
Read(Box<dyn Read + Send + 'static>),
File(File),
Child(ChildProcess),
}
```
This is in comparison to the current `RawStream` type, which is an
`Iterator<Item = Vec<u8>>` and has to allocate for each read chunk.
Currently, `PipelineData::ExternalStream` serves a weird dual role where
it is either external command output or a wrapper around `RawStream`.
`ByteStream` makes this distinction more clear (via `ByteStreamSource`)
and replaces `PipelineData::ExternalStream` in this PR:
```rust
pub enum PipelineData {
Empty,
Value(Value, Option<PipelineMetadata>),
ListStream(ListStream, Option<PipelineMetadata>),
ByteStream(ByteStream, Option<PipelineMetadata>),
}
```
The PR is relatively large, but a decent amount of it is just repetitive
changes.
This PR fixes #7017, fixes #10763, and fixes #12369.
This PR also improves performance when piping external commands. Nushell
should, in most cases, have competitive pipeline throughput compared to,
e.g., bash.
| Command | Before (MB/s) | After (MB/s) | Bash (MB/s) |
| -------------------------------------------------- | -------------:|
------------:| -----------:|
| `throughput \| rg 'x'` | 3059 | 3744 | 3739 |
| `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 |
# User-Facing Changes
- This is a breaking change for the plugin communication protocol,
because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`.
Plugins now only have to deal with a single input stream, as opposed to
the previous three streams: stdout, stderr, and exit code.
- The output of `describe` has been changed for external/byte streams.
- Temporary breaking change: `bytes starts-with` no longer works with
byte streams. This is to keep the PR smaller, and `bytes ends-with`
already does not work on byte streams.
- If a process core dumped, then instead of having a `Value::Error` in
the `exit_code` column of the output returned from `complete`, it now is
a `Value::Int` with the negation of the signal number.
# After Submitting
- Update docs and book as necessary
- Release notes (e.g., plugin protocol changes)
- Adapt/convert commands to work with byte streams (high priority is
`str length`, `bytes starts-with`, and maybe `bytes ends-with`).
- Refactor the `tee` code, Devyn has already done some work on this.
---------
Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 14:11:18 +00:00
impl From < Spanned < io ::Error > > for ShellError {
fn from ( error : Spanned < io ::Error > ) -> Self {
let Spanned { item : error , span } = error ;
if error . kind ( ) = = io ::ErrorKind ::Other {
match error . into_inner ( ) {
Some ( err ) = > match err . downcast ( ) {
Ok ( err ) = > * err ,
Err ( err ) = > Self ::IOErrorSpanned {
msg : err . to_string ( ) ,
span ,
} ,
} ,
None = > Self ::IOErrorSpanned {
msg : " unknown error " . into ( ) ,
span ,
} ,
}
} else {
Self ::IOErrorSpanned {
msg : error . to_string ( ) ,
span ,
}
2024-03-02 17:14:02 +00:00
}
}
}
Replace `ExternalStream` with new `ByteStream` type (#12774)
# Description
This PR introduces a `ByteStream` type which is a `Read`-able stream of
bytes. Internally, it has an enum over three different byte stream
sources:
```rust
pub enum ByteStreamSource {
Read(Box<dyn Read + Send + 'static>),
File(File),
Child(ChildProcess),
}
```
This is in comparison to the current `RawStream` type, which is an
`Iterator<Item = Vec<u8>>` and has to allocate for each read chunk.
Currently, `PipelineData::ExternalStream` serves a weird dual role where
it is either external command output or a wrapper around `RawStream`.
`ByteStream` makes this distinction more clear (via `ByteStreamSource`)
and replaces `PipelineData::ExternalStream` in this PR:
```rust
pub enum PipelineData {
Empty,
Value(Value, Option<PipelineMetadata>),
ListStream(ListStream, Option<PipelineMetadata>),
ByteStream(ByteStream, Option<PipelineMetadata>),
}
```
The PR is relatively large, but a decent amount of it is just repetitive
changes.
This PR fixes #7017, fixes #10763, and fixes #12369.
This PR also improves performance when piping external commands. Nushell
should, in most cases, have competitive pipeline throughput compared to,
e.g., bash.
| Command | Before (MB/s) | After (MB/s) | Bash (MB/s) |
| -------------------------------------------------- | -------------:|
------------:| -----------:|
| `throughput \| rg 'x'` | 3059 | 3744 | 3739 |
| `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 |
# User-Facing Changes
- This is a breaking change for the plugin communication protocol,
because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`.
Plugins now only have to deal with a single input stream, as opposed to
the previous three streams: stdout, stderr, and exit code.
- The output of `describe` has been changed for external/byte streams.
- Temporary breaking change: `bytes starts-with` no longer works with
byte streams. This is to keep the PR smaller, and `bytes ends-with`
already does not work on byte streams.
- If a process core dumped, then instead of having a `Value::Error` in
the `exit_code` column of the output returned from `complete`, it now is
a `Value::Int` with the negation of the signal number.
# After Submitting
- Update docs and book as necessary
- Release notes (e.g., plugin protocol changes)
- Adapt/convert commands to work with byte streams (high priority is
`str length`, `bytes starts-with`, and maybe `bytes ends-with`).
- Refactor the `tee` code, Devyn has already done some work on this.
---------
Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 14:11:18 +00:00
impl From < ShellError > for io ::Error {
fn from ( error : ShellError ) -> Self {
io ::Error ::new ( io ::ErrorKind ::Other , error )
}
}
impl From < Box < dyn std ::error ::Error > > for ShellError {
fn from ( error : Box < dyn std ::error ::Error > ) -> ShellError {
2023-11-28 12:43:51 +00:00
ShellError ::IOError {
Replace `ExternalStream` with new `ByteStream` type (#12774)
# Description
This PR introduces a `ByteStream` type which is a `Read`-able stream of
bytes. Internally, it has an enum over three different byte stream
sources:
```rust
pub enum ByteStreamSource {
Read(Box<dyn Read + Send + 'static>),
File(File),
Child(ChildProcess),
}
```
This is in comparison to the current `RawStream` type, which is an
`Iterator<Item = Vec<u8>>` and has to allocate for each read chunk.
Currently, `PipelineData::ExternalStream` serves a weird dual role where
it is either external command output or a wrapper around `RawStream`.
`ByteStream` makes this distinction more clear (via `ByteStreamSource`)
and replaces `PipelineData::ExternalStream` in this PR:
```rust
pub enum PipelineData {
Empty,
Value(Value, Option<PipelineMetadata>),
ListStream(ListStream, Option<PipelineMetadata>),
ByteStream(ByteStream, Option<PipelineMetadata>),
}
```
The PR is relatively large, but a decent amount of it is just repetitive
changes.
This PR fixes #7017, fixes #10763, and fixes #12369.
This PR also improves performance when piping external commands. Nushell
should, in most cases, have competitive pipeline throughput compared to,
e.g., bash.
| Command | Before (MB/s) | After (MB/s) | Bash (MB/s) |
| -------------------------------------------------- | -------------:|
------------:| -----------:|
| `throughput \| rg 'x'` | 3059 | 3744 | 3739 |
| `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 |
# User-Facing Changes
- This is a breaking change for the plugin communication protocol,
because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`.
Plugins now only have to deal with a single input stream, as opposed to
the previous three streams: stdout, stderr, and exit code.
- The output of `describe` has been changed for external/byte streams.
- Temporary breaking change: `bytes starts-with` no longer works with
byte streams. This is to keep the PR smaller, and `bytes ends-with`
already does not work on byte streams.
- If a process core dumped, then instead of having a `Value::Error` in
the `exit_code` column of the output returned from `complete`, it now is
a `Value::Int` with the negation of the signal number.
# After Submitting
- Update docs and book as necessary
- Release notes (e.g., plugin protocol changes)
- Adapt/convert commands to work with byte streams (high priority is
`str length`, `bytes starts-with`, and maybe `bytes ends-with`).
- Refactor the `tee` code, Devyn has already done some work on this.
---------
Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 14:11:18 +00:00
msg : error . to_string ( ) ,
2023-11-28 12:43:51 +00:00
}
2021-10-05 21:08:39 +00:00
}
}
2021-10-05 19:54:30 +00:00
impl From < Box < dyn std ::error ::Error + Send + Sync > > for ShellError {
Replace `ExternalStream` with new `ByteStream` type (#12774)
# Description
This PR introduces a `ByteStream` type which is a `Read`-able stream of
bytes. Internally, it has an enum over three different byte stream
sources:
```rust
pub enum ByteStreamSource {
Read(Box<dyn Read + Send + 'static>),
File(File),
Child(ChildProcess),
}
```
This is in comparison to the current `RawStream` type, which is an
`Iterator<Item = Vec<u8>>` and has to allocate for each read chunk.
Currently, `PipelineData::ExternalStream` serves a weird dual role where
it is either external command output or a wrapper around `RawStream`.
`ByteStream` makes this distinction more clear (via `ByteStreamSource`)
and replaces `PipelineData::ExternalStream` in this PR:
```rust
pub enum PipelineData {
Empty,
Value(Value, Option<PipelineMetadata>),
ListStream(ListStream, Option<PipelineMetadata>),
ByteStream(ByteStream, Option<PipelineMetadata>),
}
```
The PR is relatively large, but a decent amount of it is just repetitive
changes.
This PR fixes #7017, fixes #10763, and fixes #12369.
This PR also improves performance when piping external commands. Nushell
should, in most cases, have competitive pipeline throughput compared to,
e.g., bash.
| Command | Before (MB/s) | After (MB/s) | Bash (MB/s) |
| -------------------------------------------------- | -------------:|
------------:| -----------:|
| `throughput \| rg 'x'` | 3059 | 3744 | 3739 |
| `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 |
# User-Facing Changes
- This is a breaking change for the plugin communication protocol,
because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`.
Plugins now only have to deal with a single input stream, as opposed to
the previous three streams: stdout, stderr, and exit code.
- The output of `describe` has been changed for external/byte streams.
- Temporary breaking change: `bytes starts-with` no longer works with
byte streams. This is to keep the PR smaller, and `bytes ends-with`
already does not work on byte streams.
- If a process core dumped, then instead of having a `Value::Error` in
the `exit_code` column of the output returned from `complete`, it now is
a `Value::Int` with the negation of the signal number.
# After Submitting
- Update docs and book as necessary
- Release notes (e.g., plugin protocol changes)
- Adapt/convert commands to work with byte streams (high priority is
`str length`, `bytes starts-with`, and maybe `bytes ends-with`).
- Refactor the `tee` code, Devyn has already done some work on this.
---------
Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 14:11:18 +00:00
fn from ( error : Box < dyn std ::error ::Error + Send + Sync > ) -> ShellError {
2023-11-28 12:43:51 +00:00
ShellError ::IOError {
Replace `ExternalStream` with new `ByteStream` type (#12774)
# Description
This PR introduces a `ByteStream` type which is a `Read`-able stream of
bytes. Internally, it has an enum over three different byte stream
sources:
```rust
pub enum ByteStreamSource {
Read(Box<dyn Read + Send + 'static>),
File(File),
Child(ChildProcess),
}
```
This is in comparison to the current `RawStream` type, which is an
`Iterator<Item = Vec<u8>>` and has to allocate for each read chunk.
Currently, `PipelineData::ExternalStream` serves a weird dual role where
it is either external command output or a wrapper around `RawStream`.
`ByteStream` makes this distinction more clear (via `ByteStreamSource`)
and replaces `PipelineData::ExternalStream` in this PR:
```rust
pub enum PipelineData {
Empty,
Value(Value, Option<PipelineMetadata>),
ListStream(ListStream, Option<PipelineMetadata>),
ByteStream(ByteStream, Option<PipelineMetadata>),
}
```
The PR is relatively large, but a decent amount of it is just repetitive
changes.
This PR fixes #7017, fixes #10763, and fixes #12369.
This PR also improves performance when piping external commands. Nushell
should, in most cases, have competitive pipeline throughput compared to,
e.g., bash.
| Command | Before (MB/s) | After (MB/s) | Bash (MB/s) |
| -------------------------------------------------- | -------------:|
------------:| -----------:|
| `throughput \| rg 'x'` | 3059 | 3744 | 3739 |
| `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 |
# User-Facing Changes
- This is a breaking change for the plugin communication protocol,
because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`.
Plugins now only have to deal with a single input stream, as opposed to
the previous three streams: stdout, stderr, and exit code.
- The output of `describe` has been changed for external/byte streams.
- Temporary breaking change: `bytes starts-with` no longer works with
byte streams. This is to keep the PR smaller, and `bytes ends-with`
already does not work on byte streams.
- If a process core dumped, then instead of having a `Value::Error` in
the `exit_code` column of the output returned from `complete`, it now is
a `Value::Int` with the negation of the signal number.
# After Submitting
- Update docs and book as necessary
- Release notes (e.g., plugin protocol changes)
- Adapt/convert commands to work with byte streams (high priority is
`str length`, `bytes starts-with`, and maybe `bytes ends-with`).
- Refactor the `tee` code, Devyn has already done some work on this.
---------
Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 14:11:18 +00:00
msg : format ! ( " {error:?} " ) ,
2023-11-28 12:43:51 +00:00
}
2021-10-05 19:54:30 +00:00
}
2021-09-02 01:29:43 +00:00
}
2021-11-07 21:48:50 +00:00
2024-03-21 11:27:21 +00:00
impl From < super ::LabeledError > for ShellError {
Replace `ExternalStream` with new `ByteStream` type (#12774)
# Description
This PR introduces a `ByteStream` type which is a `Read`-able stream of
bytes. Internally, it has an enum over three different byte stream
sources:
```rust
pub enum ByteStreamSource {
Read(Box<dyn Read + Send + 'static>),
File(File),
Child(ChildProcess),
}
```
This is in comparison to the current `RawStream` type, which is an
`Iterator<Item = Vec<u8>>` and has to allocate for each read chunk.
Currently, `PipelineData::ExternalStream` serves a weird dual role where
it is either external command output or a wrapper around `RawStream`.
`ByteStream` makes this distinction more clear (via `ByteStreamSource`)
and replaces `PipelineData::ExternalStream` in this PR:
```rust
pub enum PipelineData {
Empty,
Value(Value, Option<PipelineMetadata>),
ListStream(ListStream, Option<PipelineMetadata>),
ByteStream(ByteStream, Option<PipelineMetadata>),
}
```
The PR is relatively large, but a decent amount of it is just repetitive
changes.
This PR fixes #7017, fixes #10763, and fixes #12369.
This PR also improves performance when piping external commands. Nushell
should, in most cases, have competitive pipeline throughput compared to,
e.g., bash.
| Command | Before (MB/s) | After (MB/s) | Bash (MB/s) |
| -------------------------------------------------- | -------------:|
------------:| -----------:|
| `throughput \| rg 'x'` | 3059 | 3744 | 3739 |
| `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 |
# User-Facing Changes
- This is a breaking change for the plugin communication protocol,
because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`.
Plugins now only have to deal with a single input stream, as opposed to
the previous three streams: stdout, stderr, and exit code.
- The output of `describe` has been changed for external/byte streams.
- Temporary breaking change: `bytes starts-with` no longer works with
byte streams. This is to keep the PR smaller, and `bytes ends-with`
already does not work on byte streams.
- If a process core dumped, then instead of having a `Value::Error` in
the `exit_code` column of the output returned from `complete`, it now is
a `Value::Int` with the negation of the signal number.
# After Submitting
- Update docs and book as necessary
- Release notes (e.g., plugin protocol changes)
- Adapt/convert commands to work with byte streams (high priority is
`str length`, `bytes starts-with`, and maybe `bytes ends-with`).
- Refactor the `tee` code, Devyn has already done some work on this.
---------
Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 14:11:18 +00:00
fn from ( error : super ::LabeledError ) -> Self {
ShellError ::LabeledError ( Box ::new ( error ) )
2024-03-21 11:27:21 +00:00
}
}
2024-03-30 13:21:40 +00:00
/// `ShellError` always serializes as [`LabeledError`].
impl Serialize for ShellError {
fn serialize < S > ( & self , serializer : S ) -> Result < S ::Ok , S ::Error >
where
S : serde ::Serializer ,
{
LabeledError ::from_diagnostic ( self ) . serialize ( serializer )
}
}
/// `ShellError` always deserializes as if it were [`LabeledError`], resulting in a
/// [`ShellError::LabeledError`] variant.
impl < ' de > Deserialize < ' de > for ShellError {
fn deserialize < D > ( deserializer : D ) -> Result < Self , D ::Error >
where
D : serde ::Deserializer < ' de > ,
{
LabeledError ::deserialize ( deserializer ) . map ( ShellError ::from )
}
}
2022-06-30 01:01:34 +00:00
pub fn into_code ( err : & ShellError ) -> Option < String > {
err . code ( ) . map ( | code | code . to_string ( ) )
}
2024-03-30 13:21:40 +00:00
#[ test ]
fn shell_error_serialize_roundtrip ( ) {
// Ensure that we can serialize and deserialize `ShellError`, and check that it basically would
// look the same
let original_error = ShellError ::CantConvert {
span : Span ::new ( 100 , 200 ) ,
to_type : " Foo " . into ( ) ,
from_type : " Bar " . into ( ) ,
help : Some ( " this is a test " . into ( ) ) ,
} ;
println! ( " orig_error = {:#?} " , original_error ) ;
let serialized =
serde_json ::to_string_pretty ( & original_error ) . expect ( " serde_json::to_string_pretty failed " ) ;
println! ( " serialized = {} " , serialized ) ;
let deserialized : ShellError =
serde_json ::from_str ( & serialized ) . expect ( " serde_json::from_str failed " ) ;
println! ( " deserialized = {:#?} " , deserialized ) ;
// We don't expect the deserialized error to be the same as the original error, but its miette
// properties should be comparable
assert_eq! ( original_error . to_string ( ) , deserialized . to_string ( ) ) ;
assert_eq! (
original_error . code ( ) . map ( | c | c . to_string ( ) ) ,
deserialized . code ( ) . map ( | c | c . to_string ( ) )
) ;
let orig_labels = original_error
. labels ( )
. into_iter ( )
. flatten ( )
. collect ::< Vec < _ > > ( ) ;
let deser_labels = deserialized
. labels ( )
. into_iter ( )
. flatten ( )
. collect ::< Vec < _ > > ( ) ;
assert_eq! ( orig_labels , deser_labels ) ;
assert_eq! (
original_error . help ( ) . map ( | c | c . to_string ( ) ) ,
deserialized . help ( ) . map ( | c | c . to_string ( ) )
) ;
}
