nushell/src/run.rs

292 lines
8.0 KiB
Rust
Raw Normal View History

#[cfg(feature = "plugin")]
use crate::config_files::NUSHELL_FOLDER;
use crate::{
command,
config_files::{self, setup_config},
};
#[cfg(feature = "plugin")]
use nu_cli::read_plugin_file;
use nu_cli::{evaluate_commands, evaluate_file, evaluate_repl};
2023-09-01 08:18:55 +02:00
use nu_protocol::eval_const::create_nu_constant;
use nu_protocol::{PipelineData, Span, NU_VARIABLE_ID};
use nu_utils::utils::perf;
pub(crate) fn run_commands(
engine_state: &mut nu_protocol::engine::EngineState,
parsed_nu_cli_args: command::NushellCliArgs,
use_color: bool,
commands: &nu_protocol::Spanned<String>,
input: PipelineData,
entire_start_time: std::time::Instant,
) -> Result<(), miette::ErrReport> {
let mut stack = nu_protocol::engine::Stack::new();
let start_time = std::time::Instant::now();
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
// if the --no-config-file(-n) option is NOT passed, load the plugin file,
// load the default env file or custom (depending on parsed_nu_cli_args.env_file),
// and maybe a custom config file (depending on parsed_nu_cli_args.config_file)
//
// if the --no-config-file(-n) flag is passed, do not load plugin, env, or config files
if parsed_nu_cli_args.no_config_file.is_none() {
#[cfg(feature = "plugin")]
read_plugin_file(
engine_state,
&mut stack,
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
parsed_nu_cli_args.plugin_file,
NUSHELL_FOLDER,
);
allow `--login` to be used with nu's `--commands` parameter (#10253) # Description This PR allows the `--login`/`-l` parameter to be used with nushell's `--commands`/`-c` parameter. When you do this, since you're invoking it with the `-l` flag, nushell will load your env.nu, config.nu, and login.nu, in that order. Then it will proceed to run your commands. I think this provides a better quality of life when you want to run scripts with your personal config files as a login shell. ### Before (these entries are from the default_env.nu) ![image](https://github.com/nushell/nushell/assets/343840/ce7adcd0-419e-485c-b7d1-f11f162e8e9e) ### After (these entries are from my personal env.nu) ![image](https://github.com/nushell/nushell/assets/343840/33bbc06b-983c-4461-8274-290e4c712506) closes https://github.com/nushell/nushell/issues/9833 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-09-06 20:27:16 +02:00
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
perf(
"read plugins",
start_time,
file!(),
line!(),
column!(),
use_color,
);
let start_time = std::time::Instant::now();
allow `--login` to be used with nu's `--commands` parameter (#10253) # Description This PR allows the `--login`/`-l` parameter to be used with nushell's `--commands`/`-c` parameter. When you do this, since you're invoking it with the `-l` flag, nushell will load your env.nu, config.nu, and login.nu, in that order. Then it will proceed to run your commands. I think this provides a better quality of life when you want to run scripts with your personal config files as a login shell. ### Before (these entries are from the default_env.nu) ![image](https://github.com/nushell/nushell/assets/343840/ce7adcd0-419e-485c-b7d1-f11f162e8e9e) ### After (these entries are from my personal env.nu) ![image](https://github.com/nushell/nushell/assets/343840/33bbc06b-983c-4461-8274-290e4c712506) closes https://github.com/nushell/nushell/issues/9833 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-09-06 20:27:16 +02:00
// If we have a env file parameter *OR* we have a login shell parameter, read the env file
if parsed_nu_cli_args.env_file.is_some() || parsed_nu_cli_args.login_shell.is_some() {
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
config_files::read_config_file(
engine_state,
&mut stack,
parsed_nu_cli_args.env_file,
true,
);
} else {
config_files::read_default_env_file(engine_state, &mut stack)
}
allow `--login` to be used with nu's `--commands` parameter (#10253) # Description This PR allows the `--login`/`-l` parameter to be used with nushell's `--commands`/`-c` parameter. When you do this, since you're invoking it with the `-l` flag, nushell will load your env.nu, config.nu, and login.nu, in that order. Then it will proceed to run your commands. I think this provides a better quality of life when you want to run scripts with your personal config files as a login shell. ### Before (these entries are from the default_env.nu) ![image](https://github.com/nushell/nushell/assets/343840/ce7adcd0-419e-485c-b7d1-f11f162e8e9e) ### After (these entries are from my personal env.nu) ![image](https://github.com/nushell/nushell/assets/343840/33bbc06b-983c-4461-8274-290e4c712506) closes https://github.com/nushell/nushell/issues/9833 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-09-06 20:27:16 +02:00
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
perf(
"read env.nu",
start_time,
file!(),
line!(),
column!(),
use_color,
);
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
let start_time = std::time::Instant::now();
allow `--login` to be used with nu's `--commands` parameter (#10253) # Description This PR allows the `--login`/`-l` parameter to be used with nushell's `--commands`/`-c` parameter. When you do this, since you're invoking it with the `-l` flag, nushell will load your env.nu, config.nu, and login.nu, in that order. Then it will proceed to run your commands. I think this provides a better quality of life when you want to run scripts with your personal config files as a login shell. ### Before (these entries are from the default_env.nu) ![image](https://github.com/nushell/nushell/assets/343840/ce7adcd0-419e-485c-b7d1-f11f162e8e9e) ### After (these entries are from my personal env.nu) ![image](https://github.com/nushell/nushell/assets/343840/33bbc06b-983c-4461-8274-290e4c712506) closes https://github.com/nushell/nushell/issues/9833 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-09-06 20:27:16 +02:00
// If we have a config file parameter *OR* we have a login shell parameter, read the config file
if parsed_nu_cli_args.config_file.is_some() || parsed_nu_cli_args.login_shell.is_some() {
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
config_files::read_config_file(
engine_state,
&mut stack,
parsed_nu_cli_args.config_file,
false,
);
}
allow `--login` to be used with nu's `--commands` parameter (#10253) # Description This PR allows the `--login`/`-l` parameter to be used with nushell's `--commands`/`-c` parameter. When you do this, since you're invoking it with the `-l` flag, nushell will load your env.nu, config.nu, and login.nu, in that order. Then it will proceed to run your commands. I think this provides a better quality of life when you want to run scripts with your personal config files as a login shell. ### Before (these entries are from the default_env.nu) ![image](https://github.com/nushell/nushell/assets/343840/ce7adcd0-419e-485c-b7d1-f11f162e8e9e) ### After (these entries are from my personal env.nu) ![image](https://github.com/nushell/nushell/assets/343840/33bbc06b-983c-4461-8274-290e4c712506) closes https://github.com/nushell/nushell/issues/9833 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-09-06 20:27:16 +02:00
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
perf(
"read config.nu",
start_time,
file!(),
line!(),
column!(),
use_color,
);
allow `--login` to be used with nu's `--commands` parameter (#10253) # Description This PR allows the `--login`/`-l` parameter to be used with nushell's `--commands`/`-c` parameter. When you do this, since you're invoking it with the `-l` flag, nushell will load your env.nu, config.nu, and login.nu, in that order. Then it will proceed to run your commands. I think this provides a better quality of life when you want to run scripts with your personal config files as a login shell. ### Before (these entries are from the default_env.nu) ![image](https://github.com/nushell/nushell/assets/343840/ce7adcd0-419e-485c-b7d1-f11f162e8e9e) ### After (these entries are from my personal env.nu) ![image](https://github.com/nushell/nushell/assets/343840/33bbc06b-983c-4461-8274-290e4c712506) closes https://github.com/nushell/nushell/issues/9833 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-09-06 20:27:16 +02:00
// If we have a login shell parameter, read the login file
let start_time = std::time::Instant::now();
if parsed_nu_cli_args.login_shell.is_some() {
config_files::read_loginshell_file(engine_state, &mut stack);
}
perf(
"read login.nu",
start_time,
file!(),
line!(),
column!(),
use_color,
);
if --no-config-file(-n) is passed, do not load config files with -c (#9286) # Description I noticed recently these timing discrepancies. I was thinking they would be nearly identical but they were not. ``` > nu --no-std-lib -n -c "$nu.startup-time" 13ms 686µs 209ns > nu --no-std-lib -n > $nu.startup-time 2ms 520µs 416ns ``` My research showed that if `-n` was passed with `-c`, then the `-n` was essentially being ignored. This PR corrects that. Also worthy of understanding, if `nu -c "some command"` is passed, the default env file is always loaded. I believe that's on purpose so that a NU_LIB_DIRS env is available. ## After this PR (on a different system) ``` > nu --no-std-lib -n -c "$nu.startup-time" 6ms 688µs 600ns > nu -n --no-std-lib > $nu.startup-time 6ms 661µs 800ns ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2023-05-25 15:24:56 +02:00
}
2023-09-01 08:18:55 +02:00
// Before running commands, set up the startup time
engine_state.set_startup_time(entire_start_time.elapsed().as_nanos() as i64);
2023-09-01 08:18:55 +02:00
// Regenerate the $nu constant to contain the startup time and any other potential updates
let nu_const = create_nu_constant(engine_state, commands.span)?;
engine_state.set_variable_const_val(NU_VARIABLE_ID, nu_const);
let start_time = std::time::Instant::now();
let ret_val = evaluate_commands(
commands,
engine_state,
&mut stack,
input,
parsed_nu_cli_args.table_mode,
);
perf(
"evaluate_commands",
start_time,
file!(),
line!(),
column!(),
use_color,
);
match ret_val {
Ok(Some(exit_code)) => std::process::exit(exit_code as i32),
Ok(None) => Ok(()),
Err(e) => Err(e),
}
}
pub(crate) fn run_file(
engine_state: &mut nu_protocol::engine::EngineState,
parsed_nu_cli_args: command::NushellCliArgs,
use_color: bool,
script_name: String,
args_to_script: Vec<String>,
input: PipelineData,
) -> Result<(), miette::ErrReport> {
let mut stack = nu_protocol::engine::Stack::new();
let start_time = std::time::Instant::now();
#[cfg(feature = "plugin")]
read_plugin_file(
engine_state,
&mut stack,
parsed_nu_cli_args.plugin_file,
NUSHELL_FOLDER,
);
perf(
"read plugins",
start_time,
file!(),
line!(),
column!(),
use_color,
);
let start_time = std::time::Instant::now();
// only want to load config and env if relative argument is provided.
if parsed_nu_cli_args.env_file.is_some() {
config_files::read_config_file(engine_state, &mut stack, parsed_nu_cli_args.env_file, true);
} else {
config_files::read_default_env_file(engine_state, &mut stack)
}
perf(
"read env.nu",
start_time,
file!(),
line!(),
column!(),
use_color,
);
let start_time = std::time::Instant::now();
if parsed_nu_cli_args.config_file.is_some() {
config_files::read_config_file(
engine_state,
&mut stack,
parsed_nu_cli_args.config_file,
false,
);
}
perf(
"read config.nu",
start_time,
file!(),
line!(),
column!(),
use_color,
);
2023-09-01 08:18:55 +02:00
// Regenerate the $nu constant to contain the startup time and any other potential updates
let nu_const = create_nu_constant(engine_state, input.span().unwrap_or_else(Span::unknown))?;
engine_state.set_variable_const_val(NU_VARIABLE_ID, nu_const);
let start_time = std::time::Instant::now();
let ret_val = evaluate_file(
script_name,
&args_to_script,
engine_state,
&mut stack,
input,
);
perf(
"evaluate_file",
start_time,
file!(),
line!(),
column!(),
use_color,
);
let start_time = std::time::Instant::now();
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_int();
if let Ok(value) = value {
if value != 0 {
std::process::exit(value as i32);
}
}
}
perf(
"get exit code",
start_time,
file!(),
line!(),
column!(),
use_color,
);
ret_val
}
pub(crate) fn run_repl(
FEATURE: add the startup time to `$nu` (#8353) # Description in https://github.com/nushell/nushell/issues/8311 and the discord server, the idea of moving the default banner from the `rust` source to the `nushell` standar library has emerged :yum: however, in order to do this, one need to have access to all the variables used in the default banner => all of them are accessible because known constants, except for the startup time of the shell, which is not anywhere in the shell... #### this PR adds exactly this, i.e. the new `startup_time` to the `$nu` variable, which is computed to have the exact same value as the value shown in the banner. ## the changes in order to achieve this, i had to - add `startup_time` as an `i64` to the `EngineState` => this is, to the best of my knowledge, the easiest way to pass such an information around down to where the banner startup time is computed and where the `$nu` variable is evaluated - add `startup-time` to the `$nu` variable and use the `EngineState` getter for `startup_time` to show it as a `Value::Duration` - pass `engine_state` as a `&mut`able argument from `main.rs` down to `repl.rs` to allow the setter to change the value of `startup_time` => without this, the value would not change and would show `-1ns` as the default value... - the value of the startup time is computed in `evaluate_repl` in `repl.rs`, only once at the beginning, and the same value is used in the default banner :ok_hand: # User-Facing Changes one can now access to the same time as shown in the default banner with ```bash $nu.startup-time ``` # Tests + Formatting - :green_circle: `cargo fmt --all` - :green_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` - :green_circle: `cargo test --workspace` # After Submitting ``` $nothing ```
2023-03-09 21:18:58 +01:00
engine_state: &mut nu_protocol::engine::EngineState,
parsed_nu_cli_args: command::NushellCliArgs,
entire_start_time: std::time::Instant,
) -> Result<(), miette::ErrReport> {
let mut stack = nu_protocol::engine::Stack::new();
let start_time = std::time::Instant::now();
if parsed_nu_cli_args.no_config_file.is_none() {
setup_config(
FEATURE: add the startup time to `$nu` (#8353) # Description in https://github.com/nushell/nushell/issues/8311 and the discord server, the idea of moving the default banner from the `rust` source to the `nushell` standar library has emerged :yum: however, in order to do this, one need to have access to all the variables used in the default banner => all of them are accessible because known constants, except for the startup time of the shell, which is not anywhere in the shell... #### this PR adds exactly this, i.e. the new `startup_time` to the `$nu` variable, which is computed to have the exact same value as the value shown in the banner. ## the changes in order to achieve this, i had to - add `startup_time` as an `i64` to the `EngineState` => this is, to the best of my knowledge, the easiest way to pass such an information around down to where the banner startup time is computed and where the `$nu` variable is evaluated - add `startup-time` to the `$nu` variable and use the `EngineState` getter for `startup_time` to show it as a `Value::Duration` - pass `engine_state` as a `&mut`able argument from `main.rs` down to `repl.rs` to allow the setter to change the value of `startup_time` => without this, the value would not change and would show `-1ns` as the default value... - the value of the startup time is computed in `evaluate_repl` in `repl.rs`, only once at the beginning, and the same value is used in the default banner :ok_hand: # User-Facing Changes one can now access to the same time as shown in the default banner with ```bash $nu.startup-time ``` # Tests + Formatting - :green_circle: `cargo fmt --all` - :green_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` - :green_circle: `cargo test --workspace` # After Submitting ``` $nothing ```
2023-03-09 21:18:58 +01:00
engine_state,
&mut stack,
#[cfg(feature = "plugin")]
parsed_nu_cli_args.plugin_file,
parsed_nu_cli_args.config_file,
parsed_nu_cli_args.env_file,
parsed_nu_cli_args.login_shell.is_some(),
);
}
// Reload use_color from config in case it's different from the default value
let use_color = engine_state.get_config().use_ansi_coloring;
perf(
"setup_config",
start_time,
file!(),
line!(),
column!(),
use_color,
);
let start_time = std::time::Instant::now();
let ret_val = evaluate_repl(
FEATURE: add the startup time to `$nu` (#8353) # Description in https://github.com/nushell/nushell/issues/8311 and the discord server, the idea of moving the default banner from the `rust` source to the `nushell` standar library has emerged :yum: however, in order to do this, one need to have access to all the variables used in the default banner => all of them are accessible because known constants, except for the startup time of the shell, which is not anywhere in the shell... #### this PR adds exactly this, i.e. the new `startup_time` to the `$nu` variable, which is computed to have the exact same value as the value shown in the banner. ## the changes in order to achieve this, i had to - add `startup_time` as an `i64` to the `EngineState` => this is, to the best of my knowledge, the easiest way to pass such an information around down to where the banner startup time is computed and where the `$nu` variable is evaluated - add `startup-time` to the `$nu` variable and use the `EngineState` getter for `startup_time` to show it as a `Value::Duration` - pass `engine_state` as a `&mut`able argument from `main.rs` down to `repl.rs` to allow the setter to change the value of `startup_time` => without this, the value would not change and would show `-1ns` as the default value... - the value of the startup time is computed in `evaluate_repl` in `repl.rs`, only once at the beginning, and the same value is used in the default banner :ok_hand: # User-Facing Changes one can now access to the same time as shown in the default banner with ```bash $nu.startup-time ``` # Tests + Formatting - :green_circle: `cargo fmt --all` - :green_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` - :green_circle: `cargo test --workspace` # After Submitting ``` $nothing ```
2023-03-09 21:18:58 +01:00
engine_state,
&mut stack,
config_files::NUSHELL_FOLDER,
parsed_nu_cli_args.execute,
parsed_nu_cli_args.no_std_lib,
entire_start_time,
);
perf(
"evaluate_repl",
start_time,
file!(),
line!(),
column!(),
use_color,
);
ret_val
}