bdb6daa4b5
This is the first PR towards migrating to a new `$env.PWD` API that returns potentially un-canonicalized paths. Refer to PR #12515 for motivations. ## New API: `EngineState::cwd()` The goal of the new API is to cover both parse-time and runtime use case, and avoid unintentional misuse. It takes an `Option<Stack>` as argument, which if supplied, will search for `$env.PWD` on the stack in additional to the engine state. I think with this design, there's less confusion over parse-time and runtime environments. If you have access to a stack, just supply it; otherwise supply `None`. ## Deprecation of other PWD-related APIs Other APIs are re-implemented using `EngineState::cwd()` and properly documented. They're marked deprecated, but their behavior is unchanged. Unused APIs are deleted, and code that accesses `$env.PWD` directly without using an API is rewritten. Deprecated APIs: * `EngineState::current_work_dir()` * `StateWorkingSet::get_cwd()` * `env::current_dir()` * `env::current_dir_str()` * `env::current_dir_const()` * `env::current_dir_str_const()` Other changes: * `EngineState::get_cwd()` (deleted) * `StateWorkingSet::list_env()` (deleted) * `repl::do_run_cmd()` (rewritten with `env::current_dir_str()`) ## `cd` and `pwd` now use logical paths by default This pulls the changes from PR #12515. It's currently somewhat broken because using non-canonicalized paths exposed a bug in our path normalization logic (Issue #12602). Once that is fixed, this should work. ## Future plans This PR needs some tests. Which test helpers should I use, and where should I put those tests? I noticed that unquoted paths are expanded within `eval_filepath()` and `eval_directory()` before they even reach the `cd` command. This means every paths is expanded twice. Is this intended? Once this PR lands, the plan is to review all usages of the deprecated APIs and migrate them to `EngineState::cwd()`. In the meantime, these usages are annotated with `#[allow(deprecated)]` to avoid breaking CI. --------- Co-authored-by: Jakub Žádník <kubouch@gmail.com> |
||
---|---|---|
.. | ||
src | ||
std | ||
tests | ||
Cargo.toml | ||
CONTRIBUTING.md | ||
LICENSE | ||
README.md | ||
testing.nu |
Welcome to the standard library of `nushell`!
The standard library is a pure-nushell
collection of custom commands which
provide interactive utilities and building blocks for users writing casual scripts or complex applications.
To see what's here:
> use std
> scope commands | select name usage | where name =~ "std "
#┬───────────name────────────┬──────────────────────usage──────────────────────
0│std assert │Universal assert command
1│std assert equal │Assert $left == $right
2│std assert error │Assert that executing the code generates an error
3│std assert greater │Assert $left > $right
4│std assert greater or equal│Assert $left >= $right
... ...
─┴───────────────────────────┴─────────────────────────────────────────────────
🧰 Using the standard library in the REPL or in scripts
All commands in the standard library must be "imported" into the running environment
(the interactive read-execute-print-loop (REPL) or a .nu
script) using the
use
command.
You can choose to import the whole module, but then must refer to individual commands with a std
prefix, e.g:
use std
std log debug "Running now"
std assert (1 == 2)
Or you can enumerate the specific commands you want to import and invoke them without the std
prefix.
use std ["log debug" assert]
log debug "Running again"
assert (2 == 1)
This is probably the form of import you'll want to add to your env.nu
for interactive use.
✏️ contribute to the standard library
You're invited to contribute to the standard library! See CONTRIBUTING.md for details