fix(scripts): resolve invoke_separator by parse success, not python3 availability (#3304)#3320
Open
Noor-ul-ain001 wants to merge 1 commit into
Open
Conversation
…back (github#3304) `get_invoke_separator` in common.sh selected its JSON parser by tool *availability* (`command -v python3`) rather than parse *success*, and had no text fallback after the python3 branch. On stock Windows + Git Bash — no jq, and `python3` resolving to the Microsoft Store App Execution Alias stub that passes `command -v` but exits 49 at runtime — it silently fell back to "." even for `-`-separator integrations (e.g. forge, cline). The observable result was wrong command hints in error messages, such as `/speckit.plan` instead of `/speckit-plan`, in check-prerequisites.sh and setup-tasks.sh. This is the same existence-vs-runtime pattern fixed for the feature.json parser in github#3304's primary report; the reporter explicitly asked that other python3 call sites be checked. The two remaining sites (resolve_template, resolve_template_content) already fall through on failure and are unaffected. - Restructure the jq -> python3 chain to fall through on parse failure, gated on a `parsed` success flag rather than exclusive elif branches. - Make the python3 branch signal failure (sys.exit(1)) instead of printing "." so a stub failure falls through instead of being accepted. - Add an awk text fallback (portable, no gawk-only whole-file slurp) that reads the active integration key and its invoke_separator, handling both pretty-printed (the written form) and compact JSON. Malformed input safely defaults to ".". Regression test simulates the broken-stub environment (jq + python3 stubs that exit 49 on PATH) and asserts the `-` separator is still recovered. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #3304. The primary report and PR #3312 fix the
feature.jsonparser (
read_feature_json_feature_directory), but the reporter explicitlyasked that other
python3call sites be grepped for the same pattern.This fixes the one remaining site that has the defect:
get_invoke_separator.get_invoke_separatorinscripts/bash/common.shselected its JSON parser bytool availability (
command -v python3) rather than parse success, and —unlike the feature.json parser — had no text fallback at all after the
python3 branch. On a stock Windows machine under Git Bash (no
jq;python3resolving to the Microsoft Store App Execution Alias stub that satisfies
command -vbut exits 49 at runtime), it silently returned"."even forintegrations that use a
-separator (e.g.forge,cline).The observable symptom is wrong command hints in user-facing error messages
—
check-prerequisites.shandsetup-tasks.shprint e.g.Run /speckit.plan firstinstead of the correct/speckit-plan.Changes
scripts/bash/common.sh(get_invoke_separator):jq → python3cascade to fall through on parse failure,gated on a
parsedsuccess flag rather than exclusiveelif-on-availabilitybranches (mirrors the approach in fix(scripts): fall through to grep/sed when python3 is a broken stub in feature.json parser #3312).
sys.exit(1)) instead ofprinting
".", so a stub failure falls through instead of being accepted asa valid answer.
jqnor a workingpython3. It reads the active integration key (default_integration, elseintegration) and itsinvoke_separatorfrom withinintegration_settings.Portable (no gawk-only
RS="^$"whole-file slurp, so BSD awk / macOS isfine) and handles both pretty-printed (the written form) and compact JSON.
Malformed input safely defaults to
".".tests/test_setup_tasks.py: regression test that simulates the brokenenvironment (
jq+python3stubs that exit 49, prepended toPATH) andasserts the
-separator is still recovered (/speckit-plan).Scope note
The other two
python3call sites incommon.sh(resolve_template,resolve_template_content) already wrap the call inif …python3…; then … else <fallback> fi, so a stub failure correctly falls into their unordered-scanfallback. They are unaffected and left unchanged. This PR does not touch
read_feature_json_feature_directory(covered by #3312), so the two PRs arenon-overlapping.
Verification
Reproduced on a machine that is the affected environment (no jq,
python3=Windows Store stub): before the fix
format_speckit_command planemits/speckit.plan; after,/speckit-plan. Validated the parser across pretty /compact / dot-default / empty-settings / malformed inputs, and under
set -euo pipefail.🤖 Generated with Claude Code