2019-08-15 07:02:02 +02:00
|
|
|
use crate::commands::WholeStreamCommand;
|
2019-06-27 18:47:24 +02:00
|
|
|
use crate::prelude::*;
|
2019-07-16 09:08:35 +02:00
|
|
|
use derive_new::new;
|
Add support for ~ expansion
This ended up being a bit of a yak shave. The basic idea in this commit is to
expand `~` in paths, but only in paths.
The way this is accomplished is by doing the expansion inside of the code that
parses literal syntax for `SyntaxType::Path`.
As a quick refresher: every command is entitled to expand its arguments in a
custom way. While this could in theory be used for general-purpose macros,
today the expansion facility is limited to syntactic hints.
For example, the syntax `where cpu > 0` expands under the hood to
`where { $it.cpu > 0 }`. This happens because the first argument to `where`
is defined as a `SyntaxType::Block`, and the parser coerces binary expressions
whose left-hand-side looks like a member into a block when the command is
expecting one.
This is mildly more magical than what most programming languages would do,
but we believe that it makes sense to allow commands to fine-tune the syntax
because of the domain nushell is in (command-line shells).
The syntactic expansions supported by this facility are relatively limited.
For example, we don't allow `$it` to become a bare word, simply because the
command asks for a string in the relevant position. That would quickly
become more confusing than it's worth.
This PR adds a new `SyntaxType` rule: `SyntaxType::Path`. When a command
declares a parameter as a `SyntaxType::Path`, string literals and bare
words passed as an argument to that parameter are processed using the
path expansion rules. Right now, that only means that `~` is expanded into
the home directory, but additional rules are possible in the future.
By restricting this expansion to a syntactic expansion when passed as an
argument to a command expecting a path, we avoid making `~` a generally
reserved character. This will also allow us to give good tab completion
for paths with `~` characters in them when a command is expecting a path.
In order to accomplish the above, this commit changes the parsing functions
to take a `Context` instead of just a `CommandRegistry`. From the perspective
of macro expansion, you can think of the `CommandRegistry` as a dictionary
of in-scope macros, and the `Context` as the compile-time state used in
expansion. This could gain additional functionality over time as we find
more uses for the expansion system.
2019-08-26 21:21:03 +02:00
|
|
|
use log::trace;
|
Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
use nu_errors::ShellError;
|
2020-05-16 05:18:24 +02:00
|
|
|
use nu_protocol::{ReturnSuccess, ReturnValue, Signature, UntaggedValue, Value};
|
2019-06-27 18:47:24 +02:00
|
|
|
use serde::{self, Deserialize, Serialize};
|
|
|
|
use std::io::prelude::*;
|
|
|
|
use std::io::BufReader;
|
2019-06-29 10:55:42 +02:00
|
|
|
use std::io::Write;
|
2019-06-27 18:47:24 +02:00
|
|
|
|
|
|
|
#[derive(Debug, Serialize, Deserialize)]
|
|
|
|
pub struct JsonRpc<T> {
|
|
|
|
jsonrpc: String,
|
|
|
|
pub method: String,
|
|
|
|
pub params: T,
|
|
|
|
}
|
2019-06-29 10:55:42 +02:00
|
|
|
|
2019-06-27 18:47:24 +02:00
|
|
|
impl<T> JsonRpc<T> {
|
|
|
|
pub fn new<U: Into<String>>(method: U, params: T) -> Self {
|
|
|
|
JsonRpc {
|
|
|
|
jsonrpc: "2.0".into(),
|
|
|
|
method: method.into(),
|
|
|
|
params,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Serialize, Deserialize)]
|
|
|
|
#[serde(tag = "method")]
|
|
|
|
#[allow(non_camel_case_types)]
|
|
|
|
pub enum NuResult {
|
2019-07-02 09:56:20 +02:00
|
|
|
response {
|
|
|
|
params: Result<VecDeque<ReturnValue>, ShellError>,
|
|
|
|
},
|
2019-06-27 18:47:24 +02:00
|
|
|
}
|
|
|
|
|
2019-07-16 09:08:35 +02:00
|
|
|
#[derive(new)]
|
|
|
|
pub struct PluginCommand {
|
|
|
|
name: String,
|
|
|
|
path: String,
|
Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
config: Signature,
|
2019-07-16 09:08:35 +02:00
|
|
|
}
|
|
|
|
|
2019-08-15 07:02:02 +02:00
|
|
|
impl WholeStreamCommand for PluginCommand {
|
2019-08-02 21:15:07 +02:00
|
|
|
fn name(&self) -> &str {
|
|
|
|
&self.name
|
|
|
|
}
|
|
|
|
|
Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
fn signature(&self) -> Signature {
|
2019-08-02 21:15:07 +02:00
|
|
|
self.config.clone()
|
|
|
|
}
|
|
|
|
|
2019-08-30 00:52:32 +02:00
|
|
|
fn usage(&self) -> &str {
|
|
|
|
&self.config.usage
|
|
|
|
}
|
|
|
|
|
2019-07-24 00:22:11 +02:00
|
|
|
fn run(
|
|
|
|
&self,
|
|
|
|
args: CommandArgs,
|
|
|
|
registry: &CommandRegistry,
|
|
|
|
) -> Result<OutputStream, ShellError> {
|
|
|
|
filter_plugin(self.path.clone(), args, registry)
|
2019-07-16 09:08:35 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-07-24 00:22:11 +02:00
|
|
|
pub fn filter_plugin(
|
|
|
|
path: String,
|
|
|
|
args: CommandArgs,
|
|
|
|
registry: &CommandRegistry,
|
|
|
|
) -> Result<OutputStream, ShellError> {
|
Add support for ~ expansion
This ended up being a bit of a yak shave. The basic idea in this commit is to
expand `~` in paths, but only in paths.
The way this is accomplished is by doing the expansion inside of the code that
parses literal syntax for `SyntaxType::Path`.
As a quick refresher: every command is entitled to expand its arguments in a
custom way. While this could in theory be used for general-purpose macros,
today the expansion facility is limited to syntactic hints.
For example, the syntax `where cpu > 0` expands under the hood to
`where { $it.cpu > 0 }`. This happens because the first argument to `where`
is defined as a `SyntaxType::Block`, and the parser coerces binary expressions
whose left-hand-side looks like a member into a block when the command is
expecting one.
This is mildly more magical than what most programming languages would do,
but we believe that it makes sense to allow commands to fine-tune the syntax
because of the domain nushell is in (command-line shells).
The syntactic expansions supported by this facility are relatively limited.
For example, we don't allow `$it` to become a bare word, simply because the
command asks for a string in the relevant position. That would quickly
become more confusing than it's worth.
This PR adds a new `SyntaxType` rule: `SyntaxType::Path`. When a command
declares a parameter as a `SyntaxType::Path`, string literals and bare
words passed as an argument to that parameter are processed using the
path expansion rules. Right now, that only means that `~` is expanded into
the home directory, but additional rules are possible in the future.
By restricting this expansion to a syntactic expansion when passed as an
argument to a command expecting a path, we avoid making `~` a generally
reserved character. This will also allow us to give good tab completion
for paths with `~` characters in them when a command is expecting a path.
In order to accomplish the above, this commit changes the parsing functions
to take a `Context` instead of just a `CommandRegistry`. From the perspective
of macro expansion, you can think of the `CommandRegistry` as a dictionary
of in-scope macros, and the `Context` as the compile-time state used in
expansion. This could gain additional functionality over time as we find
more uses for the expansion system.
2019-08-26 21:21:03 +02:00
|
|
|
trace!("filter_plugin :: {}", path);
|
2020-05-16 05:18:24 +02:00
|
|
|
let registry = registry.clone();
|
Add support for ~ expansion
This ended up being a bit of a yak shave. The basic idea in this commit is to
expand `~` in paths, but only in paths.
The way this is accomplished is by doing the expansion inside of the code that
parses literal syntax for `SyntaxType::Path`.
As a quick refresher: every command is entitled to expand its arguments in a
custom way. While this could in theory be used for general-purpose macros,
today the expansion facility is limited to syntactic hints.
For example, the syntax `where cpu > 0` expands under the hood to
`where { $it.cpu > 0 }`. This happens because the first argument to `where`
is defined as a `SyntaxType::Block`, and the parser coerces binary expressions
whose left-hand-side looks like a member into a block when the command is
expecting one.
This is mildly more magical than what most programming languages would do,
but we believe that it makes sense to allow commands to fine-tune the syntax
because of the domain nushell is in (command-line shells).
The syntactic expansions supported by this facility are relatively limited.
For example, we don't allow `$it` to become a bare word, simply because the
command asks for a string in the relevant position. That would quickly
become more confusing than it's worth.
This PR adds a new `SyntaxType` rule: `SyntaxType::Path`. When a command
declares a parameter as a `SyntaxType::Path`, string literals and bare
words passed as an argument to that parameter are processed using the
path expansion rules. Right now, that only means that `~` is expanded into
the home directory, but additional rules are possible in the future.
By restricting this expansion to a syntactic expansion when passed as an
argument to a command expecting a path, we avoid making `~` a generally
reserved character. This will also allow us to give good tab completion
for paths with `~` characters in them when a command is expecting a path.
In order to accomplish the above, this commit changes the parsing functions
to take a `Context` instead of just a `CommandRegistry`. From the perspective
of macro expansion, you can think of the `CommandRegistry` as a dictionary
of in-scope macros, and the `Context` as the compile-time state used in
expansion. This could gain additional functionality over time as we find
more uses for the expansion system.
2019-08-26 21:21:03 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
let scope = args
|
2020-04-15 07:43:23 +02:00
|
|
|
.call_info
|
|
|
|
.scope
|
|
|
|
.clone()
|
|
|
|
.set_it(UntaggedValue::string("$it").into_untagged_value());
|
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
let stream = async_stream! {
|
|
|
|
let mut args = args.evaluate_once_with_scope(®istry, &scope).await?;
|
2019-06-27 18:47:24 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
let mut child = std::process::Command::new(path)
|
|
|
|
.stdin(std::process::Stdio::piped())
|
|
|
|
.stdout(std::process::Stdio::piped())
|
|
|
|
.spawn()
|
|
|
|
.expect("Failed to spawn child process");
|
2019-06-29 10:55:42 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
let call_info = args.call_info.clone();
|
2019-06-27 18:47:24 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
trace!("filtering :: {:?}", call_info);
|
2019-07-27 09:45:00 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
// Beginning of the stream
|
|
|
|
{
|
|
|
|
let stdin = child.stdin.as_mut().expect("Failed to open stdin");
|
|
|
|
let stdout = child.stdout.as_mut().expect("Failed to open stdout");
|
Add support for ~ expansion
This ended up being a bit of a yak shave. The basic idea in this commit is to
expand `~` in paths, but only in paths.
The way this is accomplished is by doing the expansion inside of the code that
parses literal syntax for `SyntaxType::Path`.
As a quick refresher: every command is entitled to expand its arguments in a
custom way. While this could in theory be used for general-purpose macros,
today the expansion facility is limited to syntactic hints.
For example, the syntax `where cpu > 0` expands under the hood to
`where { $it.cpu > 0 }`. This happens because the first argument to `where`
is defined as a `SyntaxType::Block`, and the parser coerces binary expressions
whose left-hand-side looks like a member into a block when the command is
expecting one.
This is mildly more magical than what most programming languages would do,
but we believe that it makes sense to allow commands to fine-tune the syntax
because of the domain nushell is in (command-line shells).
The syntactic expansions supported by this facility are relatively limited.
For example, we don't allow `$it` to become a bare word, simply because the
command asks for a string in the relevant position. That would quickly
become more confusing than it's worth.
This PR adds a new `SyntaxType` rule: `SyntaxType::Path`. When a command
declares a parameter as a `SyntaxType::Path`, string literals and bare
words passed as an argument to that parameter are processed using the
path expansion rules. Right now, that only means that `~` is expanded into
the home directory, but additional rules are possible in the future.
By restricting this expansion to a syntactic expansion when passed as an
argument to a command expecting a path, we avoid making `~` a generally
reserved character. This will also allow us to give good tab completion
for paths with `~` characters in them when a command is expecting a path.
In order to accomplish the above, this commit changes the parsing functions
to take a `Context` instead of just a `CommandRegistry`. From the perspective
of macro expansion, you can think of the `CommandRegistry` as a dictionary
of in-scope macros, and the `Context` as the compile-time state used in
expansion. This could gain additional functionality over time as we find
more uses for the expansion system.
2019-08-26 21:21:03 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
let mut reader = BufReader::new(stdout);
|
2019-07-27 09:45:00 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
let request = JsonRpc::new("begin_filter", call_info.clone());
|
|
|
|
let request_raw = serde_json::to_string(&request);
|
2019-07-27 09:45:00 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
match request_raw {
|
|
|
|
Err(_) => {
|
|
|
|
yield Err(ShellError::labeled_error(
|
|
|
|
"Could not load json from plugin",
|
|
|
|
"could not load json from plugin",
|
|
|
|
&call_info.name_tag,
|
|
|
|
));
|
Add support for ~ expansion
This ended up being a bit of a yak shave. The basic idea in this commit is to
expand `~` in paths, but only in paths.
The way this is accomplished is by doing the expansion inside of the code that
parses literal syntax for `SyntaxType::Path`.
As a quick refresher: every command is entitled to expand its arguments in a
custom way. While this could in theory be used for general-purpose macros,
today the expansion facility is limited to syntactic hints.
For example, the syntax `where cpu > 0` expands under the hood to
`where { $it.cpu > 0 }`. This happens because the first argument to `where`
is defined as a `SyntaxType::Block`, and the parser coerces binary expressions
whose left-hand-side looks like a member into a block when the command is
expecting one.
This is mildly more magical than what most programming languages would do,
but we believe that it makes sense to allow commands to fine-tune the syntax
because of the domain nushell is in (command-line shells).
The syntactic expansions supported by this facility are relatively limited.
For example, we don't allow `$it` to become a bare word, simply because the
command asks for a string in the relevant position. That would quickly
become more confusing than it's worth.
This PR adds a new `SyntaxType` rule: `SyntaxType::Path`. When a command
declares a parameter as a `SyntaxType::Path`, string literals and bare
words passed as an argument to that parameter are processed using the
path expansion rules. Right now, that only means that `~` is expanded into
the home directory, but additional rules are possible in the future.
By restricting this expansion to a syntactic expansion when passed as an
argument to a command expecting a path, we avoid making `~` a generally
reserved character. This will also allow us to give good tab completion
for paths with `~` characters in them when a command is expecting a path.
In order to accomplish the above, this commit changes the parsing functions
to take a `Context` instead of just a `CommandRegistry`. From the perspective
of macro expansion, you can think of the `CommandRegistry` as a dictionary
of in-scope macros, and the `Context` as the compile-time state used in
expansion. This could gain additional functionality over time as we find
more uses for the expansion system.
2019-08-26 21:21:03 +02:00
|
|
|
}
|
2020-05-16 05:18:24 +02:00
|
|
|
Ok(request_raw) => match stdin.write(format!("{}\n", request_raw).as_bytes()) {
|
|
|
|
Ok(_) => {}
|
Add support for ~ expansion
This ended up being a bit of a yak shave. The basic idea in this commit is to
expand `~` in paths, but only in paths.
The way this is accomplished is by doing the expansion inside of the code that
parses literal syntax for `SyntaxType::Path`.
As a quick refresher: every command is entitled to expand its arguments in a
custom way. While this could in theory be used for general-purpose macros,
today the expansion facility is limited to syntactic hints.
For example, the syntax `where cpu > 0` expands under the hood to
`where { $it.cpu > 0 }`. This happens because the first argument to `where`
is defined as a `SyntaxType::Block`, and the parser coerces binary expressions
whose left-hand-side looks like a member into a block when the command is
expecting one.
This is mildly more magical than what most programming languages would do,
but we believe that it makes sense to allow commands to fine-tune the syntax
because of the domain nushell is in (command-line shells).
The syntactic expansions supported by this facility are relatively limited.
For example, we don't allow `$it` to become a bare word, simply because the
command asks for a string in the relevant position. That would quickly
become more confusing than it's worth.
This PR adds a new `SyntaxType` rule: `SyntaxType::Path`. When a command
declares a parameter as a `SyntaxType::Path`, string literals and bare
words passed as an argument to that parameter are processed using the
path expansion rules. Right now, that only means that `~` is expanded into
the home directory, but additional rules are possible in the future.
By restricting this expansion to a syntactic expansion when passed as an
argument to a command expecting a path, we avoid making `~` a generally
reserved character. This will also allow us to give good tab completion
for paths with `~` characters in them when a command is expecting a path.
In order to accomplish the above, this commit changes the parsing functions
to take a `Context` instead of just a `CommandRegistry`. From the perspective
of macro expansion, you can think of the `CommandRegistry` as a dictionary
of in-scope macros, and the `Context` as the compile-time state used in
expansion. This could gain additional functionality over time as we find
more uses for the expansion system.
2019-08-26 21:21:03 +02:00
|
|
|
Err(err) => {
|
2020-05-16 05:18:24 +02:00
|
|
|
yield Err(ShellError::unexpected(format!("{}", err)));
|
Add support for ~ expansion
This ended up being a bit of a yak shave. The basic idea in this commit is to
expand `~` in paths, but only in paths.
The way this is accomplished is by doing the expansion inside of the code that
parses literal syntax for `SyntaxType::Path`.
As a quick refresher: every command is entitled to expand its arguments in a
custom way. While this could in theory be used for general-purpose macros,
today the expansion facility is limited to syntactic hints.
For example, the syntax `where cpu > 0` expands under the hood to
`where { $it.cpu > 0 }`. This happens because the first argument to `where`
is defined as a `SyntaxType::Block`, and the parser coerces binary expressions
whose left-hand-side looks like a member into a block when the command is
expecting one.
This is mildly more magical than what most programming languages would do,
but we believe that it makes sense to allow commands to fine-tune the syntax
because of the domain nushell is in (command-line shells).
The syntactic expansions supported by this facility are relatively limited.
For example, we don't allow `$it` to become a bare word, simply because the
command asks for a string in the relevant position. That would quickly
become more confusing than it's worth.
This PR adds a new `SyntaxType` rule: `SyntaxType::Path`. When a command
declares a parameter as a `SyntaxType::Path`, string literals and bare
words passed as an argument to that parameter are processed using the
path expansion rules. Right now, that only means that `~` is expanded into
the home directory, but additional rules are possible in the future.
By restricting this expansion to a syntactic expansion when passed as an
argument to a command expecting a path, we avoid making `~` a generally
reserved character. This will also allow us to give good tab completion
for paths with `~` characters in them when a command is expecting a path.
In order to accomplish the above, this commit changes the parsing functions
to take a `Context` instead of just a `CommandRegistry`. From the perspective
of macro expansion, you can think of the `CommandRegistry` as a dictionary
of in-scope macros, and the `Context` as the compile-time state used in
expansion. This could gain additional functionality over time as we find
more uses for the expansion system.
2019-08-26 21:21:03 +02:00
|
|
|
}
|
2020-05-16 05:18:24 +02:00
|
|
|
},
|
|
|
|
}
|
2019-07-26 20:40:00 +02:00
|
|
|
|
2020-05-16 05:18:24 +02:00
|
|
|
let mut input = String::new();
|
|
|
|
match reader.read_line(&mut input) {
|
|
|
|
Ok(_) => {
|
|
|
|
let response = serde_json::from_str::<NuResult>(&input);
|
|
|
|
match response {
|
|
|
|
Ok(NuResult::response { params }) => match params {
|
|
|
|
Ok(params) => for param in params { yield param },
|
2019-07-26 20:40:00 +02:00
|
|
|
Err(e) => {
|
2020-05-16 05:18:24 +02:00
|
|
|
yield ReturnValue::Err(e);
|
2019-07-26 20:40:00 +02:00
|
|
|
}
|
2020-05-16 05:18:24 +02:00
|
|
|
},
|
|
|
|
Err(e) => {
|
|
|
|
yield Err(ShellError::untagged_runtime_error(format!(
|
|
|
|
"Error while processing begin_filter response: {:?} {}",
|
|
|
|
e, input
|
|
|
|
)));
|
2019-07-26 20:40:00 +02:00
|
|
|
}
|
|
|
|
}
|
2020-05-16 05:18:24 +02:00
|
|
|
}
|
|
|
|
Err(e) => {
|
|
|
|
yield Err(ShellError::untagged_runtime_error(format!(
|
|
|
|
"Error while reading begin_filter response: {:?}",
|
|
|
|
e
|
|
|
|
)));
|
|
|
|
}
|
2019-06-27 18:47:24 +02:00
|
|
|
}
|
2020-05-16 05:18:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Stream contents
|
|
|
|
{
|
|
|
|
while let Some(v) = args.input.next().await {
|
2019-06-29 10:55:42 +02:00
|
|
|
let stdin = child.stdin.as_mut().expect("Failed to open stdin");
|
|
|
|
let stdout = child.stdout.as_mut().expect("Failed to open stdout");
|
2019-06-27 18:47:24 +02:00
|
|
|
|
|
|
|
let mut reader = BufReader::new(stdout);
|
|
|
|
|
|
|
|
let request = JsonRpc::new("filter", v);
|
2020-01-02 18:51:20 +01:00
|
|
|
let request_raw = serde_json::to_string(&request);
|
|
|
|
match request_raw {
|
|
|
|
Ok(request_raw) => {
|
|
|
|
let _ = stdin.write(format!("{}\n", request_raw).as_bytes()); // TODO: Handle error
|
|
|
|
}
|
|
|
|
Err(e) => {
|
2020-05-16 05:18:24 +02:00
|
|
|
yield Err(ShellError::untagged_runtime_error(format!(
|
2020-01-02 18:51:20 +01:00
|
|
|
"Error while processing filter response: {:?}",
|
|
|
|
e
|
2020-05-16 05:18:24 +02:00
|
|
|
)));
|
2020-01-02 18:51:20 +01:00
|
|
|
}
|
|
|
|
}
|
2019-06-27 18:47:24 +02:00
|
|
|
|
|
|
|
let mut input = String::new();
|
|
|
|
match reader.read_line(&mut input) {
|
|
|
|
Ok(_) => {
|
|
|
|
let response = serde_json::from_str::<NuResult>(&input);
|
|
|
|
match response {
|
2019-07-02 09:56:20 +02:00
|
|
|
Ok(NuResult::response { params }) => match params {
|
2020-05-16 05:18:24 +02:00
|
|
|
Ok(params) => for param in params { yield param },
|
2019-07-02 09:56:20 +02:00
|
|
|
Err(e) => {
|
2020-05-16 05:18:24 +02:00
|
|
|
yield ReturnValue::Err(e);
|
2019-07-02 09:56:20 +02:00
|
|
|
}
|
|
|
|
},
|
|
|
|
Err(e) => {
|
2020-05-16 05:18:24 +02:00
|
|
|
yield Err(ShellError::untagged_runtime_error(format!(
|
2019-11-04 16:47:03 +01:00
|
|
|
"Error while processing filter response: {:?}\n== input ==\n{}",
|
2019-07-03 22:31:15 +02:00
|
|
|
e, input
|
2020-05-16 05:18:24 +02:00
|
|
|
)));
|
2019-06-27 18:47:24 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-07-02 09:56:20 +02:00
|
|
|
Err(e) => {
|
2020-05-16 05:18:24 +02:00
|
|
|
yield Err(ShellError::untagged_runtime_error(format!(
|
2019-07-27 09:45:00 +02:00
|
|
|
"Error while reading filter response: {:?}",
|
2019-07-03 22:31:15 +02:00
|
|
|
e
|
2020-05-16 05:18:24 +02:00
|
|
|
)));
|
2019-06-27 18:47:24 +02:00
|
|
|
}
|
|
|
|
}
|
2020-05-16 05:18:24 +02:00
|
|
|
|
2019-06-27 18:47:24 +02:00
|
|
|
}
|
2020-05-16 05:18:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// End of the stream
|
|
|
|
{
|
|
|
|
let stdin = child.stdin.as_mut().expect("Failed to open stdin");
|
|
|
|
let stdout = child.stdout.as_mut().expect("Failed to open stdout");
|
|
|
|
|
|
|
|
let mut reader = BufReader::new(stdout);
|
|
|
|
|
|
|
|
let request: JsonRpc<std::vec::Vec<Value>> = JsonRpc::new("end_filter", vec![]);
|
|
|
|
let request_raw = match serde_json::to_string(&request) {
|
|
|
|
Ok(req) => req,
|
|
|
|
Err(err) => {
|
|
|
|
yield Err(ShellError::unexpected(format!("{}", err)));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
let _ = stdin.write(format!("{}\n", request_raw).as_bytes()); // TODO: Handle error
|
|
|
|
|
|
|
|
let mut input = String::new();
|
|
|
|
match reader.read_line(&mut input) {
|
|
|
|
Ok(_) => {
|
|
|
|
let response = serde_json::from_str::<NuResult>(&input);
|
|
|
|
match response {
|
|
|
|
Ok(NuResult::response { params }) => match params {
|
|
|
|
Ok(params) => {
|
|
|
|
let request: JsonRpc<std::vec::Vec<Value>> =
|
|
|
|
JsonRpc::new("quit", vec![]);
|
|
|
|
let request_raw = serde_json::to_string(&request);
|
|
|
|
match request_raw {
|
|
|
|
Ok(request_raw) => {
|
|
|
|
let _ = stdin.write(format!("{}\n", request_raw).as_bytes()); // TODO: Handle error
|
|
|
|
}
|
|
|
|
Err(e) => {
|
|
|
|
yield Err(ShellError::untagged_runtime_error(format!(
|
|
|
|
"Error while processing begin_filter response: {:?} {}",
|
|
|
|
e, input
|
|
|
|
)));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//yield ReturnValue::Ok(params)
|
|
|
|
//yield ReturnSuccess::value(Value)
|
|
|
|
}
|
|
|
|
Err(e) => {
|
|
|
|
yield ReturnValue::Err(e);
|
|
|
|
}
|
|
|
|
},
|
|
|
|
Err(e) => {
|
|
|
|
yield Err(ShellError::untagged_runtime_error(format!(
|
|
|
|
"Error while processing end_filter response: {:?} {}",
|
|
|
|
e, input
|
|
|
|
)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
Err(e) => {
|
|
|
|
yield Err(ShellError::untagged_runtime_error(format!(
|
|
|
|
"Error while reading end_filter: {:?}",
|
|
|
|
e
|
|
|
|
)));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
let _ = child.wait();
|
|
|
|
}
|
|
|
|
};
|
2019-06-27 18:47:24 +02:00
|
|
|
|
2019-07-03 22:31:15 +02:00
|
|
|
Ok(stream.to_output_stream())
|
2019-06-27 18:47:24 +02:00
|
|
|
}
|
2019-08-09 09:54:21 +02:00
|
|
|
|
|
|
|
#[derive(new)]
|
|
|
|
pub struct PluginSink {
|
|
|
|
name: String,
|
|
|
|
path: String,
|
Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
config: Signature,
|
2019-08-09 09:54:21 +02:00
|
|
|
}
|
|
|
|
|
2019-08-15 07:02:02 +02:00
|
|
|
impl WholeStreamCommand for PluginSink {
|
2019-08-09 09:54:21 +02:00
|
|
|
fn name(&self) -> &str {
|
|
|
|
&self.name
|
|
|
|
}
|
|
|
|
|
Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
fn signature(&self) -> Signature {
|
2019-08-09 09:54:21 +02:00
|
|
|
self.config.clone()
|
|
|
|
}
|
|
|
|
|
2019-08-30 00:52:32 +02:00
|
|
|
fn usage(&self) -> &str {
|
|
|
|
&self.config.usage
|
|
|
|
}
|
|
|
|
|
2019-08-09 09:54:21 +02:00
|
|
|
fn run(
|
|
|
|
&self,
|
|
|
|
args: CommandArgs,
|
|
|
|
registry: &CommandRegistry,
|
|
|
|
) -> Result<OutputStream, ShellError> {
|
|
|
|
sink_plugin(self.path.clone(), args, registry)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn sink_plugin(
|
|
|
|
path: String,
|
|
|
|
args: CommandArgs,
|
|
|
|
registry: &CommandRegistry,
|
|
|
|
) -> Result<OutputStream, ShellError> {
|
2020-05-16 05:18:24 +02:00
|
|
|
let registry = registry.clone();
|
2019-09-28 02:05:18 +02:00
|
|
|
let stream = async_stream! {
|
2020-05-16 05:18:24 +02:00
|
|
|
let args = args.evaluate_once(®istry).await?;
|
|
|
|
let call_info = args.call_info.clone();
|
|
|
|
|
Move external closer to internal (#1611)
* Refactor InputStream and affected commands.
First, making `values` private and leaning on the `Stream` implementation makes
consumes of `InputStream` less likely to have to change in the future, if we
change what an `InputStream` is internally.
Second, we're dropping `Option<InputStream>` as the input to pipelines,
internals, and externals. Instead, `InputStream.is_empty` can be used to check
for "emptiness". Empty streams are typically only ever used as the first input
to a pipeline.
* Add run_external internal command.
We want to push external commands closer to internal commands, eventually
eliminating the concept of "external" completely. This means we can consolidate
a couple of things:
- Variable evaluation (for example, `$it`, `$nu`, alias vars)
- Behaviour of whole stream vs per-item external execution
It should also make it easier for us to start introducing argument signatures
for external commands,
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
2020-04-20 05:30:44 +02:00
|
|
|
let input: Vec<Value> = args.input.collect().await;
|
2019-08-09 09:54:21 +02:00
|
|
|
|
|
|
|
let request = JsonRpc::new("sink", (call_info.clone(), input));
|
2020-01-02 18:51:20 +01:00
|
|
|
let request_raw = serde_json::to_string(&request);
|
|
|
|
if let Ok(request_raw) = request_raw {
|
|
|
|
if let Ok(mut tmpfile) = tempfile::NamedTempFile::new() {
|
|
|
|
let _ = writeln!(tmpfile, "{}", request_raw);
|
|
|
|
let _ = tmpfile.flush();
|
|
|
|
|
|
|
|
let mut child = std::process::Command::new(path)
|
|
|
|
.arg(tmpfile.path())
|
|
|
|
.spawn();
|
|
|
|
|
|
|
|
if let Ok(mut child) = child {
|
|
|
|
let _ = child.wait();
|
|
|
|
|
|
|
|
// Needed for async_stream to type check
|
|
|
|
if false {
|
|
|
|
yield ReturnSuccess::value(UntaggedValue::nothing().into_untagged_value());
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
yield Err(ShellError::untagged_runtime_error("Could not create process for sink command"));
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
yield Err(ShellError::untagged_runtime_error("Could not open file to send sink command message"));
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
yield Err(ShellError::untagged_runtime_error("Could not create message to sink command"));
|
2019-09-28 02:05:18 +02:00
|
|
|
}
|
2019-08-09 09:54:21 +02:00
|
|
|
};
|
|
|
|
Ok(OutputStream::new(stream))
|
|
|
|
}
|