extern/nushell
1
0
Fork 1
mirror of https://github.com/nushell/nushell.git synced 2025-08-26 23:55:00 +02:00
Code Issues Packages Projects Releases Wiki Activity

Fix typos and capitalization of "Unicode" (#3234)

Browse Source 
* Capitalize "Unicode"

* Fix several typos

* Fix mixed whitespace in nu-parser's tests
This commit is contained in:
Waldir Pimenta
2021-04-03 20:14:07 +01:00
committed by GitHub
parent e278ca61d1
commit 4bc9d9fd3b
20 changed files with 72 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
crates/nu-engine/README.md
View File

@@ -11,6 +11,6 @@ The following topics shall give the reader a top level understanding how various
Environment variables (or short envs) are stored in the `Scope` of the `EvaluationContext`. That means that environment variables are scoped by default and we don't use `std::env` to store envs (but make exceptions where convenient).
Nushell handles environment variables and their lifetime the following:
- At startup all existing environment variables are read and put into `Scope`. (Nushell reads existing environment variables platform independent by asking the `Host`. They will most likly come from `std::env::*`)
- At startup all existing environment variables are read and put into `Scope`. (Nushell reads existing environment variables platform independent by asking the `Host`. They will most likely come from `std::env::*`)
- Envs can also be loaded from config files. Each loaded config produces a new `ScopeFrame` with the envs of the loaded config.
- Nu-Script files and internal commands read and write env variables from / to the `Scope`. External scripts and binaries can't interact with the `Scope`. Therefore all env variables are read from the `Scope` and put into the external binaries environment-variables-memory area.

4
crates/nu-engine/src/evaluation_context.rs
View File

@@ -119,9 +119,9 @@ impl EvaluationContext {
/// If an error occurs while loading the config:
/// The config is not loaded
/// The error is returned
/// After successfull loading of the config the startup scripts are run
/// After successful loading of the config the startup scripts are run
/// as normal scripts (Errors are printed out, ...)
/// After executing the startup scripts, true is returned to indicate successfull loading
/// After executing the startup scripts, true is returned to indicate successful loading
/// of the config
//
// The rational here is that, we should not partially load any config