compat_get_comm's two MSYS branches pipe a path into xargs basename, so any executable path containing a space is split before basename sees it.
xargs word-splits on whitespace and hands every word to a single basename call. What comes back depends on how many words the path splits into, and neither shape is the binary name:
$ echo "/usr/local/bin/node" | xargs basename # control, no spaces
node
$ echo "/c/Program Files/nodejs/node.exe" | xargs basename # splits into 2
Program
$ echo "/c/Program Files/My App/agent.exe" | xargs basename # splits into 3
Program
My
agent.exe
$ basename -- "/c/Program Files/My App/agent.exe"
agent.exe
Two words lands in basename string suffix form and returns one wrong name; three or more is treated as several paths and returns several lines. Measured on macOS basename; the coreutils build shipped with Git Bash should be confirmed to behave the same before relying on the exact shape.
Two call sites on main (scripts/lib/compat.sh):
- line 136 — the
/proc/$pid/cmdline path: tr '\0' '\n' < "/proc/$pid/cmdline" | head -1 | xargs basename
- line 149 — the
ps -l fallback: ps -l -p "$pid" | awk 'NR==2{print $NF}' | xargs basename
Both are on the MSYS branch, where a space in the path is the common case rather than the exception (C:\Program Files\..., Application Support). Callers compare the result against a known binary name, so a wrong or multi-line return reads as "not this agent".
#770 reported the same defect on the POSIX branch (line 153) and scoped itself there deliberately; #771 fixes that one. This issue covers the two that remain.
Suggested fix, matching #771: capture the value into a variable and take basename -- "$value" of the whole string.
Not measured here: whether either branch is reached in practice on a current Git Bash install, and whether any open Windows pid-resolution report is caused by this rather than merely resembling it. Both need a Windows machine.
compat_get_comm's two MSYS branches pipe a path intoxargs basename, so any executable path containing a space is split beforebasenamesees it.xargsword-splits on whitespace and hands every word to a singlebasenamecall. What comes back depends on how many words the path splits into, and neither shape is the binary name:Two words lands in
basename string suffixform and returns one wrong name; three or more is treated as several paths and returns several lines. Measured on macOSbasename; the coreutils build shipped with Git Bash should be confirmed to behave the same before relying on the exact shape.Two call sites on
main(scripts/lib/compat.sh):/proc/$pid/cmdlinepath:tr '\0' '\n' < "/proc/$pid/cmdline" | head -1 | xargs basenameps -lfallback:ps -l -p "$pid" | awk 'NR==2{print $NF}' | xargs basenameBoth are on the MSYS branch, where a space in the path is the common case rather than the exception (
C:\Program Files\...,Application Support). Callers compare the result against a known binary name, so a wrong or multi-line return reads as "not this agent".#770 reported the same defect on the POSIX branch (line 153) and scoped itself there deliberately; #771 fixes that one. This issue covers the two that remain.
Suggested fix, matching #771: capture the value into a variable and take
basename -- "$value"of the whole string.Not measured here: whether either branch is reached in practice on a current Git Bash install, and whether any open Windows pid-resolution report is caused by this rather than merely resembling it. Both need a Windows machine.