Fix SC2329 false positive for functions referenced in prompt variables and command substitutions

[Copilot]

SC2329 incorrectly flagged functions as "never invoked" when they were referenced in prompt variables (PS1, PS2, PS3, PS4, PROMPT_COMMAND) or command substitutions, especially when scripts ended with exit.

#!/bin/bash
PS4func() {
    printf "%b" "+${BASH_LINENO[0]}: "
}
PS4='\r$(PS4func)'  # Function invoked via PS4 variable
set -o xtrace

echo 'hello'
exit

Changes

• Modified checkCommandIsUnreachable in Analytics.hs: Added isFunctionReferencedInCommandSubstitution helper that detects function references in:
  • Command substitutions: $(funcname) or `funcname`
  • Prompt variable assignments (PS1, PS2, PS3, PS4, PROMPT_COMMAND) - which are evaluated by bash even in single quotes
• Updated SC2329 condition: Now excludes functions that are referenced in command substitutions or prompt variables, even if the function definition appears unreachable in the CFG
• Added test coverage: prop_checkCommandIsUnreachable10 (PS4 variable) and prop_checkCommandIsUnreachable11 (backtick command substitution)
• Merged SC2317 fix branch: Includes related unreachability handling for return outside functions

The fix correctly recognizes that functions referenced in prompt variables and command substitutions are invoked indirectly, preventing false positives while preserving correct behavior for truly uninvoked functions.

Original prompt

fix this false postitive SC2329 on PS4func() which is being invoked. koalaman#3385 It appears that the exit $? at the end fools it. The PR should be against master branch on upstream koalaman/shellcheck but also be aware we just fixed another false-positive on here: https://github.com/dotysan/shellcheck/tree/copilot/fix-false-positive-sc2317

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[dotysan]

@copilot No, you are off in the weeds again. This bug doesn't occur when f is called after f(). Nor is it sane t call f before f(). This is a special case with the bash PS4 variable. And oddly triggered by the existense of exit after them. Also the $? has no bearing here. PS4func() {
printf "%b" "+${BASH_LINENO[0]}: "
}
PS4='\r$(PS4func)'
set -o xtrace

echo 'hello'
exit

[Copilot]

@copilot No, you are off in the weeds again. This bug doesn't occur when f is called after f(). Nor is it sane t call f before f(). This is a special case with the bash PS4 variable. And oddly trigger...

You're absolutely right - I misunderstood the issue. The fix now correctly handles PS4 and other prompt variables (PS1, PS2, PS3, PROMPT_COMMAND) where functions are invoked indirectly through variable evaluation, even when the function is in single quotes.

The fix detects function references in:

• Command substitutions: $(funcname) or `funcname`
• Prompt variable assignments where the function name appears in the value

Fixed in commit 5fc9fbe.