Repository navigation
Session Handoff [auto-1644]: Establish the PATH Order tool_shadow_path Names (#1644) #1864
Description
Activity
Done. #1644 fixed and merged to develop.
- PR: Establish the PATH Order tool_shadow_path Names #1867, squash-merged as 432987a.
tool_shadow_pathnow walks PATH in order and stops reporting once$BIN_DIRis reached, so a
copy behind it (no managed copy installed yet) yields no shadow while a copy ahead of it still
does.install-tools.ps1checked for the same conflation and found not to share it (winget
scope-based, not PATH-order-based).- A local-strict-review round caught a real regression in the first draft (a
$BIN_DIRPATH entry
spelled with a trailing slash compared unequal, so the managed copy read as its own shadow and
--upgradewould have deleted it). Fixed by stripping a trailing slash before comparing. - Copilot's review round raised the same class one level further (a doubled-slash or dot-segment
spelling of$BIN_DIR), confirmed pre-existing (the oldtype -P-based code had it too) and
declined on that evidence rather than fixed in this PR. - Filed two pre-existing, out-of-scope defects turned up during review, for the backlog:
- tool_shadow_path Misses a Doubled-Slash or Dot-Segment Spelling of BIN_DIR #1865 (doubled-slash/dot-segment BIN_DIR spelling)
- tool_unshadow's dpkg-query Ownership Guard Misses a Merged-usr /bin or /sbin Shadow #1866 (merged-usr dpkg-query ownership miss)
Worktree and feature branch cleaned up, base clone fast-forwarded to develop.
Next steps, in priority order
Re-read the issue and the tree rather than trusting this summary.
tool_shadow_pathinhost-setup/linux/install-tools.shestablish the PATH ordering it names. Today it returns whatevertype -Presolves whenever that is absolute and is not$BIN_DIR/<name>, so with no managed copy installed a copy sitting behind$BIN_DIRon PATH is reported as a shadow, and both callers (tool_noteandtool_unshadow, plus a third call site reading it as a condition) then state a PATH claim nothing measured. The fix the issue settles is to walk PATH and return a copy only where its directory precedes$BIN_DIR. Done looks like: a copy ahead of$BIN_DIRis still reported and handled as today, a copy behind$BIN_DIRwith no managed copy yields no shadow and no note, a constructed test (placeholder tool name, temporary directories, nothing on the host touched) covers both orderings and fails with the fix reverted, and a pull request into develop carryingCloses on promotion: #1644. Check the Windows installer underhost-setup/windows/for the same conflation, as the issue asks, and fix it in the same change only where it has the identical defect, otherwise note in the pull request what was found.External blockers
None known at pick time.
Internal dependencies
None. One issue, one lane.
State
No branch, worktree, or pull request exists for this lane yet. The worker creates
feature/auto-1644in its own worktree based on develop.Parked decision queue
Empty for this lane.
What the last round did
Nothing. This link opens the
auto-1644lane, created by theunattended-handoffpicker.What not to repeat
Nothing recorded yet.
New learnings
None yet.