fix: delete management/ncp.ps1 - it shadowed the ncp.cmd PATH shim

PowerShell resolves ExternalScript (.ps1) ahead of Application (.cmd), and both
lived in the directory the installer puts on PATH -- so in PowerShell `ncp` ran
the .ps1 and was execution-policy-bound again, the exact thing the .cmd exists
to avoid. Its other justification (giving ncp to pwsh on Linux) stopped being
true once /usr/local/bin/ncp existed: pwsh runs a PATH symlink to a shell script
as an Application. A test now prevents the file coming back.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
jon
2026-07-22 14:59:56 -05:00
co-authored by Claude Opus 4.8
parent b5564c4720
commit 786552b790
6 changed files with 22 additions and 61 deletions
+6 -1
View File
@@ -3,7 +3,12 @@ REM ncp - PATH entry point on Windows. A .cmd, not a .ps1, on purpose: PowerShel
REM execution policy governs .ps1 only, so this keeps working under the default
REM Restricted policy and from cmd, Win+R, Task Scheduler and .lnk targets - none
REM of which load a PowerShell profile. install-windows.ps1 puts this directory on
REM the machine PATH. ncp.ps1 stays for pwsh-on-Linux, where there is no PATH shim.
REM the machine PATH.
REM
REM This file must NOT be accompanied by an ncp.ps1 in the same directory:
REM PowerShell resolves ExternalScript (.ps1) ahead of Application (.cmd), so a
REM sibling ncp.ps1 wins in PowerShell and drags the execution policy back in -
REM exactly what this file exists to avoid.
REM
REM ASCII only, same rule as the .ps1 files - a test in tests/test_smoke.py enforces it.
setlocal