dsh-which
DeepSeek Harness 的命令解析取证：输入命令时实际运行的是什么——哪个 PATH 条目优先、它覆盖了什么、PATH 的结构如何，以及同一名称背后的副本是否版本一致。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:11111353535/dsh-which#7894da833582b46526b251348cd8993b70a5ce85Which 以 dsh-which 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Command resolution forensics for DeepSeek Harness. When you type node, a shell answers with a rule that is longer than people remember — PATH order, then PATHEXT on Windows or the executable bit elsewhere, with builtins short-circuiting the whole thing. dsh-which reports what that rule actually decided, what it shadowed, what shape PATH itself is in, and whether the copies behind one name agree on a version.
Every failure it names is silent. The command runs; it is just not the one you meant.
dsh-which · node
winner: C:\Program Files\nodejs\node.EXE
kind: native binary
from: PATH[0] C:\Program Files\nodejs
size: 84MB
modified: 2025-11-03T09:14:00.000Z
version: v24.13.0 (--version)
searched: 9 PATH entries
shadowed — 1 other directory holds this name:
PATH[6] C:\Users\me\scoop\shims\node.EXE native binary 84MB
↳ reports v20.11.1
⚠ the copies behind this name report different versions — the one that runs is the one at PATH[0].
That last block is the whole reason this exists. Two Node installations, one on PATH, and nothing anywhere tells you which one a command gets.
whichwhich does not exist on Windows, and where it does exist it answers a narrower question. It reports the file it found; it does not report the file it skipped.which inherits the rules under investigation. Shelling out to a resolver to explain resolution means trusting the resolver you are debugging. The rules here are reimplemented as pure functions over an injected filesystem (lib/resolve.js), so they are testable against fixtures instead of against whatever is installed on the test machine.which cd on most systems walks every PATH entry to report something that has nothing to do with what runs. This plugin says builtin and explains that PATH was never consulted..cmd shim in front of a real binary, a file that exists but was never made executable.dsh plugin add https://github.com/11111353535/dsh-which
From a checkout instead of a git host, pass the absolute path:
dsh plugin add /absolute/path/to/dsh-which
Optional configuration, in the profile's cordis.patch.yml:
- id: which
name: 'dsh-which'
config:
probeByDefault: false # run a version probe on every resolve
probeShadowedByDefault: false # probe the shadowed copies too
probeTimeoutMs: 4000
maxSweepFiles: 400
runtimes: [node, npm, pnpm, python, git]
| key | default | what it does |
|---|---|---|
probeTimeoutMs | 4000 | How long a version probe may take before it is abandoned. |
probeByDefault | false | Probe every resolve without being asked. Slower, explains more. |
probeShadowedByDefault | false | Probe the shadowed copies too. Multiplies the process spawns. |
maxSweepFiles | 400 | Files examined in one sweep, so a huge directory cannot stall a session. |
runtimes | node, npm, pnpm, yarn, bun, python, python3, pip, pip3, uv, git, rg, fd, make, pwsh, bash | Commands the environment report resolves. |
Probing is off by default because it spawns processes, and a diagnostic that costs four seconds on every call is a diagnostic people turn off.
which_resolveResolve one command and report what runs, what it shadowed, and — on request — what each copy reports as its version.
| parameter | type | |
|---|---|---|
command | string, required | A name (node) or a path (./build.sh, C:\tools\x.exe). |
probe | boolean | Run the winner with a version flag. |
probeShadowed | boolean | Probe the shadowed copies too, so versions can be compared. |
A name that resolves to nothing is an answer, not an error:
dsh-which · build
not found
the name exists on PATH but nothing with that name is runnable
searched: 45 PATH entries
the name exists, but nothing with it can run:
build not runnable 1KB
build not runnable 1KB
build not runnable 1KB
build not runnable 1KB
build not runnable 1KB
build not runnable 1KB
build not runnable 1KB
build not runnable 1KB
… and 37 more
The count is the finding; the enumeration is the evidence, and past eight directories the evidence stops being read. The lines that save an hour are the second and third: the name is on PATH, the file simply cannot run. On POSIX that means no executable bit — a shell walks right past it into later PATH entries, or fails.
An explicit path never consults PATH, and the report says so:
dsh-which · /repo/scripts/build.sh
winner: /repo/scripts/build.sh
kind: script
from: given as a path, PATH was not consulted
size: 2.3KB
searched: 0 PATH entries
which_pathThe shape of PATH itself: every entry in resolution order, with duplicates, entries whose directory is gone, and entries containing an unexpanded variable.
| parameter | type | |
|---|---|---|
showNoise | boolean | Include /usr/bin, /bin and friends, omitted by default as uninformative. |
limit | number | Maximum entries listed. Defaults to 40. |
dsh-which · PATH
9 entries · 8 unique directories
1 duplicate entry · 1 dead entry
entries, in resolution order:
[ 0] C:\Program Files\nodejs
[ 1] C:\Users\me\AppData\Roaming\npm
[ 2] C:\Windows\system32
[ 3] C:\Windows
[ 4] C:\tools\git\cmd
[ 5] C:\Program Files\nodejs — dup of [0]
[ 6] C:\Users\me\scoop\shims
[ 7] D:\old-python\Scripts — missing
[ 8] C:\Users\me\bin
Duplicates are usually an installer that prepends itself on every run. Harmless until you edit "the" entry and two copies of it remain.
Dead entries are skipped silently by every shell, so an uninstalled toolchain leaves a hole that only shows up when its command fails.
A dead entry is invisible by construction: shells skip it without a word, so the hole only surfaces later as "command not found" for something that was there yesterday. An unexpanded %USERPROFILE% is worse — it can never resolve, no matter what the variable is set to.
which_envOne page describing the command environment: platform, shell, working directory, PATH findings, PATHEXT, and where each common runtime resolves from.
| parameter | type | |
|---|---|---|
limit | number | Maximum runtimes listed. Defaults to 30. |
dsh-which · environment
platform: win32 arch x64 node v24.13.0
shell: pwsh.exe (C:\Program Files\PowerShell\7\pwsh.exe)
cwd: C:\repo
PATH: 9 entries · 8 unique
1 duplicate · 1 dead
PATHEXT: .COM .EXE .BAT .CMD
resolved runtimes:
· node C:\Program Files\nodejs\node.EXE
· npm C:\Program Files\nodejs\npm.CMD
· pnpm C:\Users\me\AppData\Roaming\npm\pnpm.CMD
· git C:\tools\git\cmd\git.EXE
✗ python not found
1 runtime(s) exist in more than one place on PATH: node
The shell line matters more than it looks. pwsh and cmd disagree about builtins and about .ps1, so a report that names the wrong shell is a report nobody should trust.
which_sweepSweep a directory of scripts and report, for each name that looks like a command, whether the copy in that directory is the one that would run.
| parameter | type | |
|---|---|---|
directory | string, required | Absolute, or relative to the workspace. |
limit | number | Maximum rows listed. Defaults to 60. |
dsh-which · sweep C:\repo\scripts
3 command(s)
1 resolve outside this directory (shown with ↪)
1 do not resolve at all
↪ build.cmd → C:\tools\build\build.cmd
· deploy.cmd C:\repo\scripts\deploy.cmd
✗ smoke.cmd does not resolve
A ↪ means a copy in this directory is not the one that runs: something earlier on PATH wins. That is the usual reason a script behaves differently when called from elsewhere.
./build and build are different programs and nothing warns you. That is the question this answers.
which_probeRun every copy of a name that resolution can find with a version flag, and report whether they agree.
| parameter | type | |
|---|---|---|
command | string, required | Command name to probe. |
dsh-which · node · version probe
winner: v24.13.0
shadowed: v20.11.1 (C:\Users\me\scoop\shims\node.EXE)
The copies report different versions. Whatever produced the other version is still installed and still on PATH.
Only a known version flag, only files resolution already picked, a four-second timeout, and 8 KB of output per probe. This is not a general command runner.
/which # the environment report
/which node # what runs
/which node --probe # and what it says its version is
/which --path # the shape of PATH
/which --env # the environment report
/which --sweep . # scripts here that resolve elsewhere
which_path; the candidate list answers "how many distinct files carry this name"..EXE before .CMD means npm and npm.cmd can be different programs, and an explicit extension is tried before PATHEXT is walked at all.cd, echo, dir, copy are answered by the shell; PATH is never consulted.java -version exits non-zero and is handled.npm run setup:deps # link the host's @deepseek-ai/* packages into ./node_modules
npm test # 88 unit and seam tests
npm run test:live # 11 checks against the real machine
node test/samples.mjs # regenerate the examples above from the plugin's own renderers
The unit tests drive pure modules with a fixture filesystem; the live check runs against the real PATH, the real PATHEXT and a real node --version, because that is the one thing fixtures cannot prove. The samples script renders the README examples from a fixed fixture with the plugin's own renderers, so an example cannot drift from the code without the regeneration showing it.
Module layout: pathlist.js (PATH itself), resolve.js (the rules), probe.js (version comparison), format.js (rendering), units.js (sizes and ages), host.js (the only module that touches the real filesystem and environment), index.js (tools and command).
MIT