forked from extern/nushell
d95375d494
* Resolve rebase artifacts * Remove leftover dependencies on removed feature * Remove unnecessary 'pub' * Start taking notes and fooling around * Split canonicalize to two versions; Add TODOs One that takes `relative_to` and one that doesn't. More TODO notes. * Merge absolutize to and rename resolve_dots * Add custom absolutize fn and use it in path expand * Convert a couple of dunce::canonicalize to ours * Update nu-path description * Replace all canonicalize with nu-path version * Remove leftover dunce dependencies * Fix broken autocd with trailing slash Trailing slash is preserved *only* in paths that do not contain "." or "..". This should be fixed in the future to cover all paths but for now it at least covers basic cases. * Use dunce::canonicalize for canonicalizing * Alow cd recovery from non-existent cwd * Disable removed canonicalize functionality tests Remove unused import * Break down nu-path into separate modules * Remove unused public imports * Remove abundant cow mapping * Fix clippy warning * Reformulate old canonicalize tests to expand_path They wouldn't work with the new canonicalize. * Canonicalize also ~ and ndots; Unify path joining Also, add doc comments in nu_path::expansions. * Add comment * Avoid expanding ndots if path is not valid UTF-8 With this change, no lossy path->string conversion should happen in the nu-path crate. * Fmt * Slight expand_tilde refactor; Add doc comments * Start nu-path integration tests * Add tests TODO * Fix docstring typo * Fix some doc strings * Add README for nu-path crate * Add a couple of canonicalize tests * Add nu-path integration tests * Add trim trailing slashes tests * Update nu-path dependency * Remove unused import * Regenerate lockfile |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| README.md | ||
Nu-Engine
Nu-engine handles most of the core logic of nushell. For example, engine handles: - Passing of data between commands - Evaluating a commands return values - Loading of user configurations
Top level introduction
The following topics shall give the reader a top level understanding how various topics are handled in nushell.
How are environment variables handled?
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 theHost. They will most likely come fromstd::env::*) - Envs can also be loaded from config files. Each loaded config produces a new
ScopeFramewith 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 theScope. Therefore all env variables are read from theScopeand put into the external binaries environment-variables-memory area.