dsh-which
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.
Why not just run which
which 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.- Shell builtins are not files.
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.
- The interesting output is the shadowed copy. "What runs" is one line. "What else answers to this name, and why is it not running" is the diagnosis — a stale global install behind a fresh local one, a
.cmd shim in front of a real binary, a file that exists but was never made executable.
- Reporting is the whole job. There is no PATH-editing tool here. A plugin that silently rewrites PATH is a plugin that breaks a machine.
Install
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.
Tools
which_resolve
Resolve 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_path
The 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_env
One 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_sweep
Sweep 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_probe
Run 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.
Slash command
/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
Behaviour
- Resolution is reimplemented, not shelled out. The rules live in pure functions over an injected filesystem, so they are tested against fixtures rather than against the machine running the tests.
- A repeated PATH entry does not double-count a file. Duplicates are reported by
which_path; the candidate list answers "how many distinct files carry this name".
- POSIX skips files that cannot run. A file with the right name and no executable bit is walked past, and the search continues into later entries — which is what a shell does, and what a listing tool hides.
- Windows PATHEXT order is honoured.
.EXE before .CMD means npm and npm.cmd can be different programs, and an explicit extension is tried before PATHEXT is walked at all.
- Builtins are not files.
cd, echo, dir, copy are answered by the shell; PATH is never consulted.
- Probing never throws. A program that hangs, exits non-zero, or does not understand the flag is a result with a reason, not an error.
java -version exits non-zero and is handled.
- Nothing is modified. No PATH editing, no file writes, no environment changes. Reporting is the whole job.
- The optional workspace service is optional. Without a workspace registry, relative paths resolve against the process directory; nothing else changes.
Development
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).
License
MIT
