mirror of
https://github.com/nushell/nushell
synced 2024-09-21 15:12:00 +00:00
0a990ed105
Prior to this change we would recover the names for known externals by looking up the span in the engine state. This would fail when using an alias for two reasons: 1. In cases where we don't have a subcommand, like this: ``` >>> extern bat [filename: string] >>> alias b = bat >>> bat some_file 'b' is not recognized as an internal or external command, operable program or batch file. ``` The problem is that after alias expansion, we replace the span of the expanded name with the original alias (this is done to alleviate non-related issues). The span contents we look up therefore contain `b`, the alias, instead of the expanded command name. 2. In cases where there's a subcommand: ``` >>> alias g = git >>> g push thread 'main' panicked at 'internal error: span missing in file contents cache', crates\nu-protocol\src\engine\engine_state.rs:474:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` In this case, the span in call starts where the expansion for the `g` alias is defined and end after `push` on the last command entered. This is not a proper span and causes a panic when we try to look it up. Note that this is the case for all expanded aliases that involve a subcommand, but we never actually try to retrieve the contents for that span in other cases. Anyway, the new way of looking up the name is arguably cleaner regardless of the issues mentioned above. But it's nice that it fixes them too. Co-authored-by: Hristo Filaretov <h.filaretov@protonmail.com> |
||
|---|---|---|
| .. | ||
| nu-cli | ||
| nu-color-config | ||
| nu-command | ||
| nu-engine | ||
| nu-glob | ||
| nu-json | ||
| nu-parser | ||
| nu-path | ||
| nu-plugin | ||
| nu-pretty-hex | ||
| nu-protocol | ||
| nu-system | ||
| nu-table | ||
| nu-term-grid | ||
| nu-test-support | ||
| nu-utils | ||
| nu_plugin_example | ||
| nu_plugin_gstat | ||
| nu_plugin_inc | ||
| nu_plugin_python | ||
| nu_plugin_query | ||
| old | ||
| README.md | ||
Nushell core libraries and plugins
These sub-crates form both the foundation for Nu and a set of plugins which extend Nu with additional functionality.
Foundational libraries are split into two kinds of crates:
- Core crates - those crates that work together to build the Nushell language engine
- Support crates - a set of crates that support the engine with additional features like JSON support, ANSI support, and more.
Plugins are likewise also split into two types:
- Core plugins - plugins that provide part of the default experience of Nu, including access to the system properties, processes, and web-connectivity features.
- Extra plugins - these plugins run a wide range of different capabilities like working with different file types, charting, viewing binary data, and more.