Nushell 仓库 scripts 目录运行指南构建、安装、覆盖率与基准测试脚本全解析【免费下载链接】nushellA new type of shell项目地址: https://gitcode.com/GitHub_Trending/nu/nushell在 nushell 仓库根目录下scripts/目录集中存放了面向开发者的全套可执行脚本——从一键编译整个工作区、批量安装所有官方插件到本地代码覆盖率生成、解析器基准测试再到跨平台虚拟环境验证。scripts/README.md用一张精炼的兼容性矩阵定义了「这些脚本到底能在哪个目录下跑、该怎么跑」。本文以该 README 为核心骨架结合仓库内 8 个脚本的真实实现逐条解读运行约定、底层自定位机制与每一步的 Cargo/LLVM 命令让你无论是维护本地 fork 还是参与 PR 验证都能直接照着执行。一、scripts/目录里到底有什么先看当前仓库scripts/下的实际内容README 矩阵 后续补充脚本文件语言/类型职责build-all-maclin.shBash构建nu及全部插件macOS/Linuxbuild-all-windows.cmdWindows CMD构建nu.exe及插件Windowsbuild-all.nuNushell跨平台构建全工作区已标记弃用改用toolkit buildcoverage-local.nuNushell基于 cargo-llvm-cov 生成lcov.info已标记弃用改用toolkit covcoverage-local.shBash与.nu版等价的全流程覆盖率脚本install-all.ps1PowerShell从本地源码安装nu与全部插件install-all.shBash同上Unixuninstall-all.shBash从 cargo bin 卸载nu与全部插件build.rs、nix/Rust / Nix构建辅助与 Nix 打包入口parser-bench-run.nu 等Nushell未列入矩阵的补充脚本见第五节二、读懂 README 的运行约定与兼容矩阵scripts/README.md的核心是一段「读表说明」和一张状态表。先逐字还原其约定x表示it works可用?表示no data available暂无数据不代表不可用。.nu脚本必须以nu .../foo.nu方式运行。.sh脚本必须以./.../foo.sh方式运行。.ps1脚本必须以powershell .../foo.ps1方式运行。若脚本名叫foo./scripts列有x表示可以在./scripts目录内运行root列有x表示可以在 nushell 仓库根目录运行anywhere列有x表示在任意目录下都能运行。原 README 的完整状态表如下逐字保留script./scripts/rootanywherebuild-all-maclin.shxxxbuild-all-windows.cmd?x?build-all.nuxxxcoverage-local.nuxxxcoverage-local.shxxxinstall-all.ps1?x?install-all.shxxxuninstall-all.shxxx由此可以得出几个可验证的结论三类 Unix/Nushell 脚本.sh与.nu都声明为 anywhere 可用即不依赖调用时的当前目录两个 Windows 专属脚本.cmd与.ps1只在仓库根目录运行被确认./scripts与anywhere两列为?因此日常最稳的调用姿势是在仓库根目录执行例如nu scripts/build-all.nu、./scripts/install-all.sh、powershell scripts/install-all.ps1。三、为什么.nu/.sh能从任意目录运行脚本自定位机制README 矩阵里anywhere x并非玄学源码写明了原理——两个实现通过脚本自身路径反推仓库根目录而不是依赖调用方cdNushell 版通过内建变量定位根目录例如 build-all.nulet repo_root ($env.CURRENT_FILE | path dirname --num-levels 2)coverage-local.nu 同理会先cd ($env.CURRENT_FILE | path dirname --num-levels 2)。CURRENT_FILE是 Nushell 提供的当前执行文件路径--num-levels 2恰好从scripts/回溯两层回到仓库根。Bash 版则用BASH_SOURCE与readlink -f解析出绝对目录见 coverage-local.shDIR$(readlink -f $(dirname ${BASH_SOURCE[0]})) REPO_ROOT$(dirname $DIR)install-all.sh、build-all-maclin.sh、uninstall-all.sh 均采用同一模式。之后所有cargo调用都在cd $REPO_ROOT或子路径的 subshell 中完成。反观.cmd/.ps1Windows 脚本直接以当前目录为基准如 install-all.ps1 的cargo install --force --path .其头部注释也明确写着Just runpowershell install-all.ps1in nushell root directory——这正是矩阵里root x而其他列为?的原因。实践结论在仓库任意位置执行nu /path/to/nushell/scripts/build-all.nu或./scripts/build-all-maclin.sh都是安全的Windows 下请先cd到仓库根目录再执行.ps1/.cmd。四、逐个脚本的使用方法与实现要点4.1 构建build-all.nu/build-all-maclin.sh/build-all-windows.cmd三个脚本目标一致先构建 Nushell 主程序再逐个构建官方插件。它们都调用cargo build --locked编译主 crate随后进入crates/plugin构建各插件build-all.nu、build-all-maclin.sh。插件清单在各脚本中略有出入这是差异点build-all.nu 构建 7 个插件nu_plugin_inc、nu_plugin_gstat、nu_plugin_query、nu_plugin_example、nu_plugin_custom_values、nu_plugin_formats、nu_plugin_polarsbuild-all-maclin.sh 构建 6 个不含nu_plugin_formatsbuild-all-windows.cmd 仅构建 5 个example、gstat、inc、query、custom_values。这些插件目录在crates/下均可逐一找到例如crates/nu_plugin_inc、crates/nu_plugin_polars等。需要注意build-all.nu 运行时会在首行打印弃用警告提示改用toolkit build命令。Nushell 仓库现已把常用开发流程整合进根目录的toolkit模块见 toolkit/mod.nu聚合了 artifact/checks/coverage/plugins 等子模块新贡献者可优先使用toolkit而非旧的 scripts。4.2 安装 / 卸载install-all.sh/install-all.ps1/uninstall-all.sh安装Unixinstall-all.shcargo install --force --path $REPO_ROOT --locked # 安装 nu 主程序 # 对 7 个插件循环执行 cargo install --force --path $REPO_ROOT/crates/$plugin--locked保证按仓库 Cargo.lock 的精确依赖版本安装--force用于覆盖已装旧版。安装Windowsinstall-all.ps1 的等价逻辑为在根目录cargo install --force --path . --locked然后对每个插件Set-Location crates/$plugin后cargo install --force --path .再返回上级。卸载uninstall-all.sh 则对cargo uninstall nu与 7 个插件逐个执行cargo uninstall将主程序与插件二进制从 cargo bin 目录移除。注意 Windows 没有对应的卸载.ps1矩阵与目录中都只提供了 Unix 版本。4.3 覆盖率coverage-local.nu/coverage-local.sh两个脚本都在本地生成lcov.info覆盖率报告前置依赖是安装cargo-llvm-covREADME 注释建议通过cargo install cargo-llvm-cov安装其完整流水线两个脚本逻辑一一对应为注入环境变量cargo llvm-cov show-env输出 coverage 所需环境变量并载入当前会话——.nu版做了巧妙的跨平台处理见 coverage-local.nu把环境输出中的双引号替换为单引号后from toml | load-env注释特别提醒 Windows 上C:\blah会被误当转义.sh版则用source (cargo llvm-cov show-env --export-prefix)coverage-local.sh。清理旧数据cargo llvm-cov clean --workspace。编译cargo build --workspace --profileci。脚本注释解释了ciprofile 的语义——它本质是 debug 构建但剥离了多余符号二进制更小、编译与运行成本更低。跑测试cargo test --workspace --profileci。产出报告cargo llvm-cov report --lcov --output-path lcov.info --profileci必须显式给出使用的 profile 才能找到原始数据。两个脚本都设置了NUSHELL_CARGO_PROFILEci环境变量coverage-local.nu / coverage-local.sh其注释解释了原因部分内部测试依赖精确的 cargo profile必须让测试感知到当前跑在ciprofile 下同时由于测试可能通过nu-test-support的nu!宏外部调用nu二进制需要手动收集才能覆盖到这些外部调用路径这正是 cargo-llvm-cov 文档所称的 external tests 场景。.nu版结尾还会打印耗时$Coverage generation took ($end - $start).。同样地coverage-local.nu 首行会打印弃用警告提示改用toolkit cov该命令确实定义于 toolkit/coverage.nuexport def cov []内部执行的是与本地脚本一致的cargo llvm-cov命令链。首次运行的坑脚本注释专门提醒需先手动执行一次cargo llvm-cov clean——rustup 工具链会弹出是否安装额外组件的确认若不做这一步脚本可能在等待yENTER处卡住。4.4 注意两处官方弃用信号通读脚本可见仓库已经把维护重心从scripts/迁移到toolkit模块build-all.nuwill be deprecated, please use thetoolkit buildcommand insteadcoverage-local.nuwill be deprecated, please use thetoolkit covcommand instead其余脚本install/uninstall/build-all-maclin 等目前没有弃用标记仍是 README 矩阵中的一等公民。若你只是本地构建/装插件直接用这些 scripts 即可若要跑 lint 格式化 全量测试的 PR 全流程则建议阅读 toolkit/mod.nu 了解toolkit各子命令。五、README 矩阵之外的补充脚本除矩阵列出的 8 个脚本外scripts/里还有几个面向专项任务的工具README 未纳入矩阵但值得知道parser-bench-run.nu运行解析器基准测试并把完整输出落盘。支持--filter默认parser_*、--bench默认benchmarks对应 benches/benchmarks.rs与--out-dir默认target/parser-bench。内部执行cargo bench -- solo --filter ...把 stdout/stderr 合并保存为带时间戳的日志文件退出码非 0 时用error make报错并提示日志位置。parser-bench-throughput.nu解析上一脚本产生的日志计算吞吐量。它从基准名中正则提取_bytesb_charsc后缀得到输入规模extract-sizes把ns/us/µs/ms/s统一换算为秒再按--time-unitsec|milli|micro|nano默认micro输出每行基准的chars_per_unit与bytes_per_unit表格并按 chars/unit 排序给出 Top-5 headline 指标。用法示例nu scripts/parser-bench-throughput.nu target/parser-bench/日志文件。test_virtualenv.nu验证 Nushell 对 Python virtualenv 激活脚本的兼容性。它创建名为e-$ èрт♞中片-j故意含 unicode/emoji的虚拟环境生成一段测试脚本依次校验激活前python可执行路径 →VIRTUAL_ENV为None→overlay use .../activate.nu后解释器切换为 venv 内路径 → 打印$env.VIRTUAL_ENV_PROMPT→deactivate后环境恢复原状全部输出与期望值比对不一致则error make报错。Windows 下还会先通过load-env修正PYTHONIOENCODING/PYTHONLEGACYWINDOWSSTDIO编码。nix/包含 default.nix 与 flake.nix 等 Nix 打包/开发入口面向 Nix 用户。六、使用建议汇总位置选择Unix 下.nu/.sh任意位置可跑脚本自定位Windows 下先把仓库根目录设为当前目录再执行.cmd/.ps1。调用前缀.nu用nu ....sh用./...需可执行权限仓库内已带x.ps1用powershell ...。前置依赖构建/安装需要 Rust 工具链与 cargo覆盖率脚本额外要求cargo-llvm-cov脚本注释建议cargo install cargo-llvm-cov且建议先手动跑一次cargo llvm-cov clean完成工具链组件确认。面向新流程build-all.nu与coverage-local.nu已被官方标记弃用替代命令是仓库根目录的toolkit build与toolkit cov做 PR 周期内的格式检查、clippy、测试可整体查阅 toolkit/mod.nu。产物约定覆盖率脚本统一输出到仓库根的lcov.info可用编辑器插件可视化基准测试日志默认落在target/parser-bench/与吞吐分析脚本配合使用。需要进一步核验的细节可直接对照 scripts/README.md 原文与上述各脚本源码阅读所有结论均有仓库内文件可查。【免费下载链接】nushellA new type of shell项目地址: https://gitcode.com/GitHub_Trending/nu/nushell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Nushell 仓库 scripts 目录运行指南构建、安装、覆盖率与基准测试脚本全解析【免费下载链接】nushellA new type of shell项目地址: https://gitcode.com/GitHub_Trending/nu/nushell在 nushell 仓库根目录下scripts/目录集中存放了面向开发者的全套可执行脚本——从一键编译整个工作区、批量安装所有官方插件到本地代码覆盖率生成、解析器基准测试再到跨平台虚拟环境验证。scripts/README.md用一张精炼的兼容性矩阵定义了「这些脚本到底能在哪个目录下跑、该怎么跑」。本文以该 README 为核心骨架结合仓库内 8 个脚本的真实实现逐条解读运行约定、底层自定位机制与每一步的 Cargo/LLVM 命令让你无论是维护本地 fork 还是参与 PR 验证都能直接照着执行。一、scripts/目录里到底有什么先看当前仓库scripts/下的实际内容README 矩阵 后续补充脚本文件语言/类型职责build-all-maclin.shBash构建nu及全部插件macOS/Linuxbuild-all-windows.cmdWindows CMD构建nu.exe及插件Windowsbuild-all.nuNushell跨平台构建全工作区已标记弃用改用toolkit buildcoverage-local.nuNushell基于 cargo-llvm-cov 生成lcov.info已标记弃用改用toolkit covcoverage-local.shBash与.nu版等价的全流程覆盖率脚本install-all.ps1PowerShell从本地源码安装nu与全部插件install-all.shBash同上Unixuninstall-all.shBash从 cargo bin 卸载nu与全部插件build.rs、nix/Rust / Nix构建辅助与 Nix 打包入口parser-bench-run.nu 等Nushell未列入矩阵的补充脚本见第五节二、读懂 README 的运行约定与兼容矩阵scripts/README.md的核心是一段「读表说明」和一张状态表。先逐字还原其约定x表示it works可用?表示no data available暂无数据不代表不可用。.nu脚本必须以nu .../foo.nu方式运行。.sh脚本必须以./.../foo.sh方式运行。.ps1脚本必须以powershell .../foo.ps1方式运行。若脚本名叫foo./scripts列有x表示可以在./scripts目录内运行root列有x表示可以在 nushell 仓库根目录运行anywhere列有x表示在任意目录下都能运行。原 README 的完整状态表如下逐字保留script./scripts/rootanywherebuild-all-maclin.shxxxbuild-all-windows.cmd?x?build-all.nuxxxcoverage-local.nuxxxcoverage-local.shxxxinstall-all.ps1?x?install-all.shxxxuninstall-all.shxxx由此可以得出几个可验证的结论三类 Unix/Nushell 脚本.sh与.nu都声明为 anywhere 可用即不依赖调用时的当前目录两个 Windows 专属脚本.cmd与.ps1只在仓库根目录运行被确认./scripts与anywhere两列为?因此日常最稳的调用姿势是在仓库根目录执行例如nu scripts/build-all.nu、./scripts/install-all.sh、powershell scripts/install-all.ps1。三、为什么.nu/.sh能从任意目录运行脚本自定位机制README 矩阵里anywhere x并非玄学源码写明了原理——两个实现通过脚本自身路径反推仓库根目录而不是依赖调用方cdNushell 版通过内建变量定位根目录例如 build-all.nulet repo_root ($env.CURRENT_FILE | path dirname --num-levels 2)coverage-local.nu 同理会先cd ($env.CURRENT_FILE | path dirname --num-levels 2)。CURRENT_FILE是 Nushell 提供的当前执行文件路径--num-levels 2恰好从scripts/回溯两层回到仓库根。Bash 版则用BASH_SOURCE与readlink -f解析出绝对目录见 coverage-local.shDIR$(readlink -f $(dirname ${BASH_SOURCE[0]})) REPO_ROOT$(dirname $DIR)install-all.sh、build-all-maclin.sh、uninstall-all.sh 均采用同一模式。之后所有cargo调用都在cd $REPO_ROOT或子路径的 subshell 中完成。反观.cmd/.ps1Windows 脚本直接以当前目录为基准如 install-all.ps1 的cargo install --force --path .其头部注释也明确写着Just runpowershell install-all.ps1in nushell root directory——这正是矩阵里root x而其他列为?的原因。实践结论在仓库任意位置执行nu /path/to/nushell/scripts/build-all.nu或./scripts/build-all-maclin.sh都是安全的Windows 下请先cd到仓库根目录再执行.ps1/.cmd。四、逐个脚本的使用方法与实现要点4.1 构建build-all.nu/build-all-maclin.sh/build-all-windows.cmd三个脚本目标一致先构建 Nushell 主程序再逐个构建官方插件。它们都调用cargo build --locked编译主 crate随后进入crates/plugin构建各插件build-all.nu、build-all-maclin.sh。插件清单在各脚本中略有出入这是差异点build-all.nu 构建 7 个插件nu_plugin_inc、nu_plugin_gstat、nu_plugin_query、nu_plugin_example、nu_plugin_custom_values、nu_plugin_formats、nu_plugin_polarsbuild-all-maclin.sh 构建 6 个不含nu_plugin_formatsbuild-all-windows.cmd 仅构建 5 个example、gstat、inc、query、custom_values。这些插件目录在crates/下均可逐一找到例如crates/nu_plugin_inc、crates/nu_plugin_polars等。需要注意build-all.nu 运行时会在首行打印弃用警告提示改用toolkit build命令。Nushell 仓库现已把常用开发流程整合进根目录的toolkit模块见 toolkit/mod.nu聚合了 artifact/checks/coverage/plugins 等子模块新贡献者可优先使用toolkit而非旧的 scripts。4.2 安装 / 卸载install-all.sh/install-all.ps1/uninstall-all.sh安装Unixinstall-all.shcargo install --force --path $REPO_ROOT --locked # 安装 nu 主程序 # 对 7 个插件循环执行 cargo install --force --path $REPO_ROOT/crates/$plugin--locked保证按仓库 Cargo.lock 的精确依赖版本安装--force用于覆盖已装旧版。安装Windowsinstall-all.ps1 的等价逻辑为在根目录cargo install --force --path . --locked然后对每个插件Set-Location crates/$plugin后cargo install --force --path .再返回上级。卸载uninstall-all.sh 则对cargo uninstall nu与 7 个插件逐个执行cargo uninstall将主程序与插件二进制从 cargo bin 目录移除。注意 Windows 没有对应的卸载.ps1矩阵与目录中都只提供了 Unix 版本。4.3 覆盖率coverage-local.nu/coverage-local.sh两个脚本都在本地生成lcov.info覆盖率报告前置依赖是安装cargo-llvm-covREADME 注释建议通过cargo install cargo-llvm-cov安装其完整流水线两个脚本逻辑一一对应为注入环境变量cargo llvm-cov show-env输出 coverage 所需环境变量并载入当前会话——.nu版做了巧妙的跨平台处理见 coverage-local.nu把环境输出中的双引号替换为单引号后from toml | load-env注释特别提醒 Windows 上C:\blah会被误当转义.sh版则用source (cargo llvm-cov show-env --export-prefix)coverage-local.sh。清理旧数据cargo llvm-cov clean --workspace。编译cargo build --workspace --profileci。脚本注释解释了ciprofile 的语义——它本质是 debug 构建但剥离了多余符号二进制更小、编译与运行成本更低。跑测试cargo test --workspace --profileci。产出报告cargo llvm-cov report --lcov --output-path lcov.info --profileci必须显式给出使用的 profile 才能找到原始数据。两个脚本都设置了NUSHELL_CARGO_PROFILEci环境变量coverage-local.nu / coverage-local.sh其注释解释了原因部分内部测试依赖精确的 cargo profile必须让测试感知到当前跑在ciprofile 下同时由于测试可能通过nu-test-support的nu!宏外部调用nu二进制需要手动收集才能覆盖到这些外部调用路径这正是 cargo-llvm-cov 文档所称的 external tests 场景。.nu版结尾还会打印耗时$Coverage generation took ($end - $start).。同样地coverage-local.nu 首行会打印弃用警告提示改用toolkit cov该命令确实定义于 toolkit/coverage.nuexport def cov []内部执行的是与本地脚本一致的cargo llvm-cov命令链。首次运行的坑脚本注释专门提醒需先手动执行一次cargo llvm-cov clean——rustup 工具链会弹出是否安装额外组件的确认若不做这一步脚本可能在等待yENTER处卡住。4.4 注意两处官方弃用信号通读脚本可见仓库已经把维护重心从scripts/迁移到toolkit模块build-all.nuwill be deprecated, please use thetoolkit buildcommand insteadcoverage-local.nuwill be deprecated, please use thetoolkit covcommand instead其余脚本install/uninstall/build-all-maclin 等目前没有弃用标记仍是 README 矩阵中的一等公民。若你只是本地构建/装插件直接用这些 scripts 即可若要跑 lint 格式化 全量测试的 PR 全流程则建议阅读 toolkit/mod.nu 了解toolkit各子命令。五、README 矩阵之外的补充脚本除矩阵列出的 8 个脚本外scripts/里还有几个面向专项任务的工具README 未纳入矩阵但值得知道parser-bench-run.nu运行解析器基准测试并把完整输出落盘。支持--filter默认parser_*、--bench默认benchmarks对应 benches/benchmarks.rs与--out-dir默认target/parser-bench。内部执行cargo bench -- solo --filter ...把 stdout/stderr 合并保存为带时间戳的日志文件退出码非 0 时用error make报错并提示日志位置。parser-bench-throughput.nu解析上一脚本产生的日志计算吞吐量。它从基准名中正则提取_bytesb_charsc后缀得到输入规模extract-sizes把ns/us/µs/ms/s统一换算为秒再按--time-unitsec|milli|micro|nano默认micro输出每行基准的chars_per_unit与bytes_per_unit表格并按 chars/unit 排序给出 Top-5 headline 指标。用法示例nu scripts/parser-bench-throughput.nu target/parser-bench/日志文件。test_virtualenv.nu验证 Nushell 对 Python virtualenv 激活脚本的兼容性。它创建名为e-$ èрт♞中片-j故意含 unicode/emoji的虚拟环境生成一段测试脚本依次校验激活前python可执行路径 →VIRTUAL_ENV为None→overlay use .../activate.nu后解释器切换为 venv 内路径 → 打印$env.VIRTUAL_ENV_PROMPT→deactivate后环境恢复原状全部输出与期望值比对不一致则error make报错。Windows 下还会先通过load-env修正PYTHONIOENCODING/PYTHONLEGACYWINDOWSSTDIO编码。nix/包含 default.nix 与 flake.nix 等 Nix 打包/开发入口面向 Nix 用户。六、使用建议汇总位置选择Unix 下.nu/.sh任意位置可跑脚本自定位Windows 下先把仓库根目录设为当前目录再执行.cmd/.ps1。调用前缀.nu用nu ....sh用./...需可执行权限仓库内已带x.ps1用powershell ...。前置依赖构建/安装需要 Rust 工具链与 cargo覆盖率脚本额外要求cargo-llvm-cov脚本注释建议cargo install cargo-llvm-cov且建议先手动跑一次cargo llvm-cov clean完成工具链组件确认。面向新流程build-all.nu与coverage-local.nu已被官方标记弃用替代命令是仓库根目录的toolkit build与toolkit cov做 PR 周期内的格式检查、clippy、测试可整体查阅 toolkit/mod.nu。产物约定覆盖率脚本统一输出到仓库根的lcov.info可用编辑器插件可视化基准测试日志默认落在target/parser-bench/与吞吐分析脚本配合使用。需要进一步核验的细节可直接对照 scripts/README.md 原文与上述各脚本源码阅读所有结论均有仓库内文件可查。【免费下载链接】nushellA new type of shell项目地址: https://gitcode.com/GitHub_Trending/nu/nushell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
