nushell/src/main.rs

794 lines
26 KiB
Rust
Raw Normal View History

2022-01-18 08:48:28 +00:00
mod config_files;
mod logger;
mod test_bins;
2021-08-10 18:57:08 +00:00
#[cfg(test)]
mod tests;
#[cfg(feature = "plugin")]
use crate::config_files::NUSHELL_FOLDER;
use crate::logger::{configure, logger};
use log::{info, Level};
2022-01-18 08:48:28 +00:00
use miette::Result;
#[cfg(feature = "plugin")]
use nu_cli::read_plugin_file;
use nu_cli::{
evaluate_commands, evaluate_file, evaluate_repl, gather_parent_env_vars, get_init_cwd,
report_error, report_error_new,
};
use nu_command::{create_default_context, BufferedReader};
use nu_engine::{get_full_help, CallExt};
use nu_parser::{escape_for_script_arg, escape_quote_string, parse};
use nu_path::canonicalize_with;
use nu_protocol::{
ast::{Call, Expr, Expression, PipelineElement},
engine::{Command, EngineState, Stack, StateWorkingSet},
Category, Example, IntoPipelineData, PipelineData, RawStream, ShellError, Signature, Spanned,
SyntaxShape, Value,
2022-01-18 08:48:28 +00:00
};
use nu_utils::stdout_write_all_and_flush;
use std::{
io::BufReader,
sync::{
atomic::{AtomicBool, Ordering},
Arc,
},
};
use std::{path::Path, str::FromStr};
// Inspired by fish's acquire_tty_or_exit
#[cfg(unix)]
fn take_control(interactive: bool) {
use nix::{
errno::Errno,
sys::signal::{self, SaFlags, SigAction, SigHandler, SigSet, Signal},
unistd::{self, Pid},
};
let shell_pgid = unistd::getpgrp();
match unistd::tcgetpgrp(nix::libc::STDIN_FILENO) {
Ok(owner_pgid) if owner_pgid == shell_pgid => {
// Common case, nothing to do
return;
}
Ok(owner_pgid) if owner_pgid == unistd::getpid() => {
// This can apparently happen with sudo: https://github.com/fish-shell/fish-shell/issues/7388
let _ = unistd::setpgid(owner_pgid, owner_pgid);
return;
}
_ => (),
}
// Reset all signal handlers to default
for sig in Signal::iterator() {
unsafe {
if let Ok(old_act) = signal::sigaction(
sig,
&SigAction::new(SigHandler::SigDfl, SaFlags::empty(), SigSet::empty()),
) {
// fish preserves ignored SIGHUP, presumably for nohup support, so let's do the same
if sig == Signal::SIGHUP && old_act.handler() == SigHandler::SigIgn {
let _ = signal::sigaction(sig, &old_act);
}
}
}
}
let mut success = false;
for _ in 0..4096 {
match unistd::tcgetpgrp(nix::libc::STDIN_FILENO) {
Ok(owner_pgid) if owner_pgid == shell_pgid => {
success = true;
break;
}
Ok(owner_pgid) if owner_pgid == Pid::from_raw(0) => {
// Zero basically means something like "not owned" and we can just take it
let _ = unistd::tcsetpgrp(nix::libc::STDIN_FILENO, shell_pgid);
}
Err(Errno::ENOTTY) => {
if !interactive {
// that's fine
return;
}
eprintln!("ERROR: no TTY for interactive shell");
std::process::exit(1);
}
_ => {
// fish also has other heuristics than "too many attempts" for the orphan check, but they're optional
if signal::killpg(Pid::from_raw(-shell_pgid.as_raw()), Signal::SIGTTIN).is_err() {
if !interactive {
// that's fine
return;
}
eprintln!("ERROR: failed to SIGTTIN ourselves");
std::process::exit(1);
}
}
}
}
if !success && interactive {
eprintln!("ERROR: failed take control of the terminal, we might be orphaned");
std::process::exit(1);
}
}
#[cfg(unix)]
fn acquire_terminal(interactive: bool) {
use nix::sys::signal::{signal, SigHandler, Signal};
if !atty::is(atty::Stream::Stdin) {
return;
}
take_control(interactive);
unsafe {
// SIGINT and SIGQUIT have special handling above
signal(Signal::SIGTSTP, SigHandler::SigIgn).expect("signal ignore");
signal(Signal::SIGTTIN, SigHandler::SigIgn).expect("signal ignore");
signal(Signal::SIGTTOU, SigHandler::SigIgn).expect("signal ignore");
// signal::signal(Signal::SIGCHLD, SigHandler::SigIgn).expect("signal ignore"); // needed for std::command's waitpid usage
}
}
#[cfg(not(unix))]
fn acquire_terminal(_: bool) {}
fn main() -> Result<()> {
// miette::set_panic_hook();
let miette_hook = std::panic::take_hook();
std::panic::set_hook(Box::new(move |x| {
2021-12-04 12:38:21 +00:00
crossterm::terminal::disable_raw_mode().expect("unable to disable raw mode");
miette_hook(x);
}));
2021-09-21 19:37:16 +00:00
Use only $nu.env.PWD for getting the current directory (#587) * Use only $nu.env.PWD for getting current directory Because setting and reading to/from std::env changes the global state shich is problematic if we call `cd` from multiple threads (e.g., in a `par-each` block). With this change, when engine-q starts, it will either inherit existing PWD env var, or create a new one from `std::env::current_dir()`. Otherwise, everything that needs the current directory will get it from `$nu.env.PWD`. Each spawned external command will get its current directory per-process which should be thread-safe. One thing left to do is to patch nu-path for this as well since it uses `std::env::current_dir()` in its expansions. * Rename nu-path functions *_with is not *_relative which should be more descriptive and frees "with" for use in a followup commit. * Clone stack every each iter; Fix some commands Cloning the stack each iteration of `each` makes sure we're not reusing PWD between iterations. Some fixes in commands to make them use the new PWD. * Post-rebase cleanup, fmt, clippy * Change back _relative to _with in nu-path funcs Didn't use the idea I had for the new "_with". * Remove leftover current_dir from rebase * Add cwd sync at merge_delta() This makes sure the parser and completer always have up-to-date cwd. * Always pass absolute path to glob in ls * Do not allow PWD a relative path; Allow recovery Makes it possible to recover PWD by proceeding with the REPL cycle. * Clone stack in each also for byte/string stream * (WIP) Start moving env variables to engine state * (WIP) Move env vars to engine state (ugly) Quick and dirty code. * (WIP) Remove unused mut and args; Fmt * (WIP) Fix dataframe tests * (WIP) Fix missing args after rebase * (WIP) Clone only env vars, not the whole stack * (WIP) Add env var clone to `for` loop as well * Minor edits * Refactor merge_delta() to include stack merging. Less error-prone than doing it manually. * Clone env for each `update` command iteration * Mark env var hidden only when found in eng. state * Fix clippt warnings * Add TODO about env var reading * Do not clone empty environment in loops * Remove extra cwd collection * Split current_dir() into str and path; Fix autocd * Make completions respect PWD env var
2022-01-04 22:30:34 +00:00
// Get initial current working directory.
let init_cwd = get_init_cwd();
let mut engine_state = create_default_context();
2021-07-17 06:31:34 +00:00
// Custom additions
let delta = {
let mut working_set = nu_protocol::engine::StateWorkingSet::new(&engine_state);
working_set.add_decl(Box::new(nu_cli::NuHighlight));
working_set.add_decl(Box::new(nu_cli::Print));
working_set.render()
};
if let Err(err) = engine_state.merge_delta(delta) {
report_error_new(&engine_state, &err);
}
2021-10-28 04:13:10 +00:00
// TODO: make this conditional in the future
// Ctrl-c protection section
let ctrlc = Arc::new(AtomicBool::new(false));
let handler_ctrlc = ctrlc.clone();
let engine_state_ctrlc = ctrlc.clone();
ctrlc::set_handler(move || {
handler_ctrlc.store(true, Ordering::SeqCst);
})
.expect("Error setting Ctrl-C handler");
engine_state.ctrlc = Some(engine_state_ctrlc);
// End ctrl-c protection section
// SIGQUIT protection section (only works for POSIX system)
#[cfg(not(windows))]
{
use signal_hook::consts::SIGQUIT;
let sig_quit = Arc::new(AtomicBool::new(false));
signal_hook::flag::register(SIGQUIT, sig_quit.clone()).expect("Error setting SIGQUIT flag");
engine_state.set_sig_quit(sig_quit);
}
// End SIGQUIT protection section
let mut args_to_nushell = vec![];
let mut script_name = String::new();
let mut args_to_script = vec![];
// Would be nice if we had a way to parse this. The first flags we see will be going to nushell
// then it'll be the script name
// then the args to the script
let mut args = std::env::args();
let argv0 = args.next();
while let Some(arg) = args.next() {
if !script_name.is_empty() {
args_to_script.push(escape_for_script_arg(&arg));
} else if arg.starts_with('-') {
// Cool, it's a flag
let flag_value = match arg.as_ref() {
2022-08-18 09:25:52 +00:00
"--commands" | "-c" | "--table-mode" | "-m" | "-e" | "--execute" => {
args.next().map(|a| escape_quote_string(&a))
}
"--config" | "--env-config" => args.next().map(|a| escape_quote_string(&a)),
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
#[cfg(feature = "plugin")]
"--plugin-config" => args.next().map(|a| escape_quote_string(&a)),
"--log-level" | "--log-target" | "--testbin" | "--threads" | "-t" => args.next(),
_ => None,
};
args_to_nushell.push(arg);
if let Some(flag_value) = flag_value {
args_to_nushell.push(flag_value);
}
} else {
// Our script file
script_name = arg;
}
}
args_to_nushell.insert(0, "nu".into());
if let Some(argv0) = argv0 {
if argv0.starts_with('-') {
args_to_nushell.push("--login".into());
}
}
let nushell_commandline_args = args_to_nushell.join(" ");
let parsed_nu_cli_args = parse_commandline_args(&nushell_commandline_args, &mut engine_state);
if let Ok(ref args) = parsed_nu_cli_args {
set_config_path(
&mut engine_state,
&init_cwd,
"config.nu",
"config-path",
&args.config_file,
);
set_config_path(
&mut engine_state,
&init_cwd,
"env.nu",
"env-path",
&args.env_file,
);
}
match parsed_nu_cli_args {
Ok(binary_args) => {
// keep this condition in sync with the branches below
acquire_terminal(
binary_args.commands.is_none()
&& (script_name.is_empty() || binary_args.interactive_shell.is_some()),
);
if let Some(t) = binary_args.threads {
// 0 means to let rayon decide how many threads to use
let threads = t.as_i64().unwrap_or(0);
rayon::ThreadPoolBuilder::new()
.num_threads(threads as usize)
.build_global()
.expect("error setting number of threads");
}
if binary_args.log_level.is_some() {
let mut level = binary_args
.log_level
.map(|level| level.item)
.unwrap_or_else(|| "info".to_string());
if Level::from_str(level.as_str()).is_err() {
eprintln!("ERROR: log library did not recognize log level '{level}', using default 'info'");
level = "info".to_string();
}
let target = binary_args
.log_target
.map(|target| target.item)
.unwrap_or_else(|| "stderr".to_string());
logger(|builder| configure(level.as_str(), target.as_str(), builder))?;
info!("start logging {}:{}:{}", file!(), line!(), column!());
}
if let Some(testbin) = &binary_args.testbin {
// Call out to the correct testbin
match testbin.item.as_str() {
"echo_env" => test_bins::echo_env(true),
"echo_env_stderr" => test_bins::echo_env(false),
"cococo" => test_bins::cococo(),
"meow" => test_bins::meow(),
"meowb" => test_bins::meowb(),
"relay" => test_bins::relay(),
"iecho" => test_bins::iecho(),
"fail" => test_bins::fail(),
"nonu" => test_bins::nonu(),
"chop" => test_bins::chop(),
"repeater" => test_bins::repeater(),
"nu_repl" => test_bins::nu_repl(),
_ => std::process::exit(1),
}
std::process::exit(0)
}
let input = if let Some(redirect_stdin) = &binary_args.redirect_stdin {
let stdin = std::io::stdin();
let buf_reader = BufReader::new(stdin);
PipelineData::ExternalStream {
stdout: Some(RawStream::new(
Box::new(BufferedReader::new(buf_reader)),
Some(ctrlc),
redirect_stdin.span,
)),
stderr: None,
exit_code: None,
span: redirect_stdin.span,
metadata: None,
Make external command substitution works friendly(like fish shell, trailing ending newlines) (#7156) # Description As title, when execute external sub command, auto-trimming end new-lines, like how fish shell does. And if the command is executed directly like: `cat tmp`, the result won't change. Fixes: #6816 Fixes: #3980 Note that although nushell works correctly by directly replace output of external command to variable(or other places like string interpolation), it's not friendly to user, and users almost want to use `str trim` to trim trailing newline, I think that's why fish shell do this automatically. If the pr is ok, as a result, no more `str trim -r` is required when user is writing scripts which using external commands. # User-Facing Changes Before: <img width="523" alt="img" src="https://user-images.githubusercontent.com/22256154/202468810-86b04dbb-c147-459a-96a5-e0095eeaab3d.png"> After: <img width="505" alt="img" src="https://user-images.githubusercontent.com/22256154/202468599-7b537488-3d6b-458e-9d75-d85780826db0.png"> # 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 --features=extra -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` to check that you're using the standard code style - `cargo test --workspace --features=extra` 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-23 03:51:57 +00:00
trim_end_newline: false,
}
} else {
PipelineData::empty()
};
info!("redirect_stdin {}:{}:{}", file!(), line!(), column!());
// First, set up env vars as strings only
gather_parent_env_vars(&mut engine_state, &init_cwd);
let mut stack = nu_protocol::engine::Stack::new();
if let Some(commands) = &binary_args.commands {
#[cfg(feature = "plugin")]
read_plugin_file(
&mut engine_state,
&mut stack,
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
binary_args.plugin_file,
NUSHELL_FOLDER,
);
2022-07-10 15:12:24 +00:00
2022-05-23 12:47:08 +00:00
// only want to load config and env if relative argument is provided.
2022-07-10 15:12:24 +00:00
if binary_args.env_file.is_some() {
2022-05-23 12:47:08 +00:00
config_files::read_config_file(
&mut engine_state,
&mut stack,
2022-07-10 15:12:24 +00:00
binary_args.env_file,
true,
);
} else {
config_files::read_default_env_file(&mut engine_state, &mut stack)
}
2022-07-10 15:12:24 +00:00
if binary_args.config_file.is_some() {
config_files::read_config_file(
&mut engine_state,
&mut stack,
2022-07-10 15:12:24 +00:00
binary_args.config_file,
false,
2022-05-23 12:47:08 +00:00
);
}
let ret_val = evaluate_commands(
commands,
&mut engine_state,
&mut stack,
input,
binary_args.table_mode,
);
info!("-c command execution {}:{}:{}", file!(), line!(), column!());
match ret_val {
Ok(Some(exit_code)) => std::process::exit(exit_code as i32),
Ok(None) => Ok(()),
Err(e) => Err(e),
}
} else if !script_name.is_empty() && binary_args.interactive_shell.is_none() {
#[cfg(feature = "plugin")]
read_plugin_file(
&mut engine_state,
&mut stack,
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
binary_args.plugin_file,
NUSHELL_FOLDER,
);
2022-07-10 15:12:24 +00:00
2022-05-23 12:47:08 +00:00
// only want to load config and env if relative argument is provided.
2022-07-10 15:12:24 +00:00
if binary_args.env_file.is_some() {
2022-05-23 12:47:08 +00:00
config_files::read_config_file(
&mut engine_state,
&mut stack,
2022-07-10 15:12:24 +00:00
binary_args.env_file,
true,
);
} else {
config_files::read_default_env_file(&mut engine_state, &mut stack)
}
2022-07-10 15:12:24 +00:00
if binary_args.config_file.is_some() {
config_files::read_config_file(
&mut engine_state,
&mut stack,
2022-07-10 15:12:24 +00:00
binary_args.config_file,
false,
2022-05-23 12:47:08 +00:00
);
}
let ret_val = evaluate_file(
script_name,
&args_to_script,
&mut engine_state,
&mut stack,
input,
);
let last_exit_code = stack.get_env_var(&engine_state, "LAST_EXIT_CODE");
if let Some(last_exit_code) = last_exit_code {
let value = last_exit_code.as_integer();
if let Ok(value) = value {
if value != 0 {
std::process::exit(value as i32);
}
}
}
info!("eval_file execution {}:{}:{}", file!(), line!(), column!());
ret_val
} else {
setup_config(
&mut engine_state,
&mut stack,
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
#[cfg(feature = "plugin")]
binary_args.plugin_file,
binary_args.config_file,
binary_args.env_file,
binary_args.login_shell.is_some(),
);
let ret_val = evaluate_repl(
&mut engine_state,
&mut stack,
config_files::NUSHELL_FOLDER,
2022-08-18 09:25:52 +00:00
binary_args.execute,
);
info!("repl eval {}:{}:{}", file!(), line!(), column!());
ret_val
}
}
Err(_) => std::process::exit(1),
}
}
fn setup_config(
engine_state: &mut EngineState,
stack: &mut Stack,
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
#[cfg(feature = "plugin")] plugin_file: Option<Spanned<String>>,
config_file: Option<Spanned<String>>,
env_file: Option<Spanned<String>>,
is_login_shell: bool,
) {
#[cfg(feature = "plugin")]
read_plugin_file(engine_state, stack, plugin_file, NUSHELL_FOLDER);
info!("read_config_file {}:{}:{}", file!(), line!(), column!());
config_files::read_config_file(engine_state, stack, env_file, true);
config_files::read_config_file(engine_state, stack, config_file, false);
if is_login_shell {
config_files::read_loginshell_file(engine_state, stack);
}
// Give a warning if we see `$config` for a few releases
{
let working_set = StateWorkingSet::new(engine_state);
if working_set.find_variable(b"$config").is_some() {
println!("warning: use `let-env config = ...` instead of `let config = ...`");
}
}
}
fn parse_commandline_args(
commandline_args: &str,
engine_state: &mut EngineState,
) -> Result<NushellCliArgs, ShellError> {
let (block, delta) = {
let mut working_set = StateWorkingSet::new(engine_state);
working_set.add_decl(Box::new(Nu));
let (output, err) = parse(
&mut working_set,
None,
commandline_args.as_bytes(),
false,
&[],
);
if let Some(err) = err {
report_error(&working_set, &err);
std::process::exit(1);
}
working_set.hide_decl(b"nu");
(output, working_set.render())
};
engine_state.merge_delta(delta)?;
let mut stack = Stack::new();
// We should have a successful parse now
if let Some(pipeline) = block.pipelines.get(0) {
if let Some(PipelineElement::Expression(
_,
Expression {
expr: Expr::Call(call),
..
},
)) = pipeline.elements.get(0)
{
let redirect_stdin = call.get_named_arg("stdin");
let login_shell = call.get_named_arg("login");
let interactive_shell = call.get_named_arg("interactive");
let commands: Option<Expression> = call.get_flag_expr("commands");
let testbin: Option<Expression> = call.get_flag_expr("testbin");
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
#[cfg(feature = "plugin")]
let plugin_file: Option<Expression> = call.get_flag_expr("plugin-config");
let config_file: Option<Expression> = call.get_flag_expr("config");
let env_file: Option<Expression> = call.get_flag_expr("env-config");
let log_level: Option<Expression> = call.get_flag_expr("log-level");
let log_target: Option<Expression> = call.get_flag_expr("log-target");
2022-08-18 09:25:52 +00:00
let execute: Option<Expression> = call.get_flag_expr("execute");
let threads: Option<Value> = call.get_flag(engine_state, &mut stack, "threads")?;
let table_mode: Option<Value> =
call.get_flag(engine_state, &mut stack, "table-mode")?;
fn extract_contents(
expression: Option<Expression>,
2022-05-01 21:49:31 +00:00
) -> Result<Option<Spanned<String>>, ShellError> {
if let Some(expr) = expression {
let str = expr.as_string();
if let Some(str) = str {
Ok(Some(Spanned {
item: str,
span: expr.span,
}))
} else {
Err(ShellError::TypeMismatch("string".into(), expr.span))
}
2022-05-01 21:49:31 +00:00
} else {
Ok(None)
}
}
2022-05-01 21:49:31 +00:00
let commands = extract_contents(commands)?;
let testbin = extract_contents(testbin)?;
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
#[cfg(feature = "plugin")]
let plugin_file = extract_contents(plugin_file)?;
2022-05-01 21:49:31 +00:00
let config_file = extract_contents(config_file)?;
let env_file = extract_contents(env_file)?;
let log_level = extract_contents(log_level)?;
let log_target = extract_contents(log_target)?;
2022-08-18 09:25:52 +00:00
let execute = extract_contents(execute)?;
let help = call.has_flag("help");
if help {
let full_help = get_full_help(
&Nu.signature(),
&Nu.examples(),
engine_state,
&mut stack,
true,
);
let _ = std::panic::catch_unwind(move || stdout_write_all_and_flush(full_help));
std::process::exit(1);
}
2022-02-17 11:02:46 +00:00
if call.has_flag("version") {
let version = env!("CARGO_PKG_VERSION").to_string();
2022-02-17 11:02:46 +00:00
let _ = std::panic::catch_unwind(move || {
stdout_write_all_and_flush(format!("{}\n", version))
2022-02-17 11:02:46 +00:00
});
std::process::exit(0);
}
return Ok(NushellCliArgs {
redirect_stdin,
login_shell,
interactive_shell,
commands,
testbin,
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
#[cfg(feature = "plugin")]
plugin_file,
config_file,
env_file,
log_level,
log_target,
2022-08-18 09:25:52 +00:00
execute,
threads,
table_mode,
});
}
}
// Just give the help and exit if the above fails
let full_help = get_full_help(
&Nu.signature(),
&Nu.examples(),
engine_state,
&mut stack,
true,
);
print!("{}", full_help);
std::process::exit(1);
}
struct NushellCliArgs {
redirect_stdin: Option<Spanned<String>>,
login_shell: Option<Spanned<String>>,
interactive_shell: Option<Spanned<String>>,
commands: Option<Spanned<String>>,
testbin: Option<Spanned<String>>,
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
#[cfg(feature = "plugin")]
plugin_file: Option<Spanned<String>>,
config_file: Option<Spanned<String>>,
env_file: Option<Spanned<String>>,
log_level: Option<Spanned<String>>,
log_target: Option<Spanned<String>>,
2022-08-18 09:25:52 +00:00
execute: Option<Spanned<String>>,
threads: Option<Value>,
table_mode: Option<Value>,
}
#[derive(Clone)]
struct Nu;
impl Command for Nu {
fn name(&self) -> &str {
"nu"
}
fn signature(&self) -> Signature {
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
let mut signature = Signature::build("nu")
.usage("The nushell language and shell.")
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
.named(
"commands",
SyntaxShape::String,
"run the given commands and then exit",
Some('c'),
)
.named(
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
"execute",
SyntaxShape::String,
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
"run the given commands and then enter an interactive shell",
Some('e'),
)
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
.switch("interactive", "start as an interactive shell", Some('i'))
.switch("login", "start as a login shell", Some('l'))
.named(
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
"table-mode",
SyntaxShape::String,
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
"the table mode to use. rounded is default.",
Some('m'),
)
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
.named(
"threads",
SyntaxShape::Int,
"threads to use for parallel commands",
Some('t'),
)
.switch("version", "print the version", Some('v'))
.named(
"config",
SyntaxShape::String,
2022-02-20 00:25:07 +00:00
"start with an alternate config file",
None,
)
.named(
"env-config",
SyntaxShape::String,
"start with an alternate environment config file",
None,
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
);
#[cfg(feature = "plugin")]
{
signature = signature.named(
"plugin-config",
SyntaxShape::String,
"start with an alternate plugin signature file",
None,
);
}
signature = signature
.named(
"log-level",
SyntaxShape::String,
"log level for diagnostic logs (error, warn, info, debug, trace). Off by default",
None,
)
.named(
"log-target",
SyntaxShape::String,
"set the target for the log to output. stdout, stderr(default), mixed or file",
None,
)
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
.switch(
"stdin",
"redirect standard input to a command (with `-c`) or a script file",
None,
)
.named(
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
"testbin",
SyntaxShape::String,
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
"run internal test binary",
None,
)
.optional(
"script file",
SyntaxShape::Filepath,
"name of the optional script file to run",
)
.rest(
"script args",
SyntaxShape::String,
"parameters to the script file",
)
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 18:29:19 +00:00
.category(Category::System);
Reorder flags in `nu --help` (#7672) The ordering of flags in `nu --help` was a bit of a mess; I think it grew organically over time. Related commands (like `--config`/`--env-config`/`--plugin-config`) weren't grouped together, common flags weren't near the top, and we weren't following alphabetical ordering. ### Before ```bash Flags: -h, --help - Display the help message for this command --stdin - redirect standard input to a command (with `-c`) or a script file -l, --login - start as a login shell -i, --interactive - start as an interactive shell -v, --version - print the version --testbin <String> - run internal test binary -c, --commands <String> - run the given commands and then exit --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file -e, --execute <String> - run the given commands and then enter an interactive shell -t, --threads <Int> - threads to use for parallel commands -m, --table-mode <String> - the table mode to use. rounded is default. --plugin-config <String> - start with an alternate plugin signature file ``` ### After ```bash Flags: -h, --help - Display the help message for this command -c, --commands <String> - run the given commands and then exit -e, --execute <String> - run the given commands and then enter an interactive shell -i, --interactive - start as an interactive shell -l, --login - start as a login shell -m, --table-mode <String> - the table mode to use. rounded is default. -t, --threads <Int> - threads to use for parallel commands -v, --version - print the version --config <String> - start with an alternate config file --env-config <String> - start with an alternate environment config file --plugin-config <String> - start with an alternate plugin signature file --log-level <String> - log level for diagnostic logs (error, warn, info, debug, trace). Off by default --log-target <String> - set the target for the log to output. stdout, stderr(default), mixed or file --stdin - redirect standard input to a command (with `-c`) or a script file --testbin <String> - run internal test binary ``` The new ordering: 1. Groups commands with short flags together, sorted alphabetically by short flag 1. Groups commands with only long flags together, sorted alphabetically (with the exception of `--plugin-config` so we can keep related flags together) Conveniently, this puts the very commonly used `-c` at the top and the very rarely used `--testbin` at the bottom.
2023-01-04 00:18:37 +00:00
signature
}
fn usage(&self) -> &str {
"The nushell language and shell."
}
fn run(
&self,
engine_state: &EngineState,
stack: &mut Stack,
call: &Call,
_input: PipelineData,
) -> Result<nu_protocol::PipelineData, nu_protocol::ShellError> {
Ok(Value::String {
val: get_full_help(&Nu.signature(), &Nu.examples(), engine_state, stack, true),
span: call.head,
}
.into_pipeline_data())
}
fn examples(&self) -> Vec<nu_protocol::Example> {
vec![
Example {
description: "Run a script",
example: "nu myfile.nu",
result: None,
},
Example {
description: "Run nushell interactively (as a shell or REPL)",
example: "nu",
result: None,
},
]
Use only $nu.env.PWD for getting the current directory (#587) * Use only $nu.env.PWD for getting current directory Because setting and reading to/from std::env changes the global state shich is problematic if we call `cd` from multiple threads (e.g., in a `par-each` block). With this change, when engine-q starts, it will either inherit existing PWD env var, or create a new one from `std::env::current_dir()`. Otherwise, everything that needs the current directory will get it from `$nu.env.PWD`. Each spawned external command will get its current directory per-process which should be thread-safe. One thing left to do is to patch nu-path for this as well since it uses `std::env::current_dir()` in its expansions. * Rename nu-path functions *_with is not *_relative which should be more descriptive and frees "with" for use in a followup commit. * Clone stack every each iter; Fix some commands Cloning the stack each iteration of `each` makes sure we're not reusing PWD between iterations. Some fixes in commands to make them use the new PWD. * Post-rebase cleanup, fmt, clippy * Change back _relative to _with in nu-path funcs Didn't use the idea I had for the new "_with". * Remove leftover current_dir from rebase * Add cwd sync at merge_delta() This makes sure the parser and completer always have up-to-date cwd. * Always pass absolute path to glob in ls * Do not allow PWD a relative path; Allow recovery Makes it possible to recover PWD by proceeding with the REPL cycle. * Clone stack in each also for byte/string stream * (WIP) Start moving env variables to engine state * (WIP) Move env vars to engine state (ugly) Quick and dirty code. * (WIP) Remove unused mut and args; Fmt * (WIP) Fix dataframe tests * (WIP) Fix missing args after rebase * (WIP) Clone only env vars, not the whole stack * (WIP) Add env var clone to `for` loop as well * Minor edits * Refactor merge_delta() to include stack merging. Less error-prone than doing it manually. * Clone env for each `update` command iteration * Mark env var hidden only when found in eng. state * Fix clippt warnings * Add TODO about env var reading * Do not clone empty environment in loops * Remove extra cwd collection * Split current_dir() into str and path; Fix autocd * Make completions respect PWD env var
2022-01-04 22:30:34 +00:00
}
2019-05-15 16:12:38 +00:00
}
fn set_config_path(
engine_state: &mut EngineState,
cwd: &Path,
default_config_name: &str,
key: &str,
config_file: &Option<Spanned<String>>,
) {
let config_path = match config_file {
Some(s) => canonicalize_with(&s.item, cwd).ok(),
None => nu_path::config_dir().map(|mut p| {
p.push(config_files::NUSHELL_FOLDER);
p.push(default_config_name);
p
}),
};
if let Some(path) = config_path {
engine_state.set_config_path(key, path);
}
}