fix(scripts): fall through to grep/sed when python3 is a broken stub in feature.json parser#3312
Merged
mnriem merged 2 commits intoJul 8, 2026
Conversation
…in feature.json parser read_feature_json_feature_directory picked its json parser by availability (if jq / elif python3 / else grep-sed). on windows `python3` usually resolves to the microsoft store app execution alias stub: it satisfies `command -v` but fails at runtime (exit 49). the elif selected it, the runtime failure was swallowed to _fd='', and the grep/sed last resort was never reached - so a valid .specify/feature.json read as empty and every setup-plan / setup-tasks / check-prerequisites call errored with "Feature directory not found" right after a successful `specify init --script sh`. change selection from availability to parse success: try jq, then python3 only if still empty, then grep/sed only if still empty. a parser that exists but produces nothing now falls through instead of terminating the chain. the write path (_persist_feature_json) already uses jq-or-printf with no python3, so it was unaffected; only the read path needed this. add a regression test that puts a python3 stub (exit 49, like the store alias) first on PATH and asserts setup-plan.sh still resolves the feature via the grep/sed fallback. fixes github#3304
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a Windows/Git Bash compatibility bug in the bash feature.json parser selection logic, where a python3 executable that exists but fails at runtime (Microsoft Store App Execution Alias stub) prevented falling back to the grep/sed parser, causing feature resolution failures right after specify init --script sh.
Changes:
- Update
read_feature_json_feature_directory()to select parsers by parse success (jq → python3 → grep/sed), not mere command availability. - Add a regression test that simulates a broken
python3onPATHand assertssetup-plan.shstill succeeds.
Show a summary per file
| File | Description |
|---|---|
scripts/bash/common.sh |
Adjusts feature.json parsing to fall through on parser failure so Windows python3 stubs don’t block grep/sed fallback. |
tests/test_setup_plan_feature_json.py |
Adds a bash-based regression test for the broken-python3 stub scenario. |
Review details
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Low
mnriem
requested changes
Jul 6, 2026
mnriem
left a comment
Collaborator
There was a problem hiding this comment.
Please address Copilot feedback
…s it the test claimed it dropped jq so the parser chain would reach python3 and then grep/sed, but it only prepended the python3 stub dir to PATH. on a runner with jq installed, read_feature_json_feature_directory parses via jq and never reaches the fallback the test is meant to cover. add a failing jq stub alongside the python3 stub so the chain is forced through jq -> python3 -> grep/sed regardless of what the runner has installed.
Contributor
Author
|
pushed 2345ac4 which adds a failing jq stub next to the python3 stub, so the chain is forced through jq -> python3 -> grep/sed no matter what the runner has installed. verified locally that with both stubs failing, grep/sed still extracts the pretty-printed feature_directory. |
mnriem
approved these changes
Jul 8, 2026
Collaborator
|
Thank you! |
kanfil
added a commit
to tikalk/agentic-sdlc-spec-kit
that referenced
this pull request
Jul 8, 2026
Upstream commits merged (7): - 94c7ec2 escape TOML control chars so generated command files parse (github#3341) - 5a901a6 fall through to grep/sed when python3 is a broken stub (github#3312) - 295eb22 port update-agent-context to Python (github#3387) - ba1ce36 remove Cursor from CLI check list in README (github#3184) - 13d2cca document missing CLI flags and integrations (github#3182) - 0da969d add LLM Wiki extension to community catalog (github#3361) - a7b4391 release 0.12.8, begin 0.12.9.dev0 (github#3410) New file: src/specify_cli/_toml_string.py Conflicts: pyproject.toml (trivial version); base.py (import block — combined fork accent() with upstream _toml_string imports). Assisted-by: OpenCode (model: glm-5.2, autonomous)
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
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.
fixes #3304
what
read_feature_json_feature_directoryinscripts/bash/common.shchose its JSON parser by availability:on windows
python3usually resolves to the microsoft store app execution alias stub. it satisfiescommand -v python3but fails at runtime (exit 49, "Python was not found..."). theelifselected it, the failure was swallowed to_fd='', and the grep/sed last resort was never reached. so a valid.specify/feature.jsonread as empty, and every script that resolves a feature this way (setup-plan.sh,setup-tasks.sh,check-prerequisites.sh, ...) errored withFeature directory not foundright after a successfulspecify init --script sh— as reported.how
select by parse success, not availability: try jq, then python3 only if the result is still empty, then grep/sed only if still empty. a parser that exists but yields nothing now falls through instead of ending the chain.
the write path (
_persist_feature_json) already uses jq-or-printfwith no python3, so it wasn't affected; only the read path needed this.verified
reproduced end-to-end with git-for-windows bash, a stub
python3(exit 49) first on PATH, and no jq:bash setup-plan.sh --json→ERROR: Feature directory not found(exit 1)plan.md(exit 0), emits the expected JSON pathsadded
test_setup_plan_survives_broken_python3_stub: writes apython3stub that exits 49, prepends it to PATH, and assertssetup-plan.shstill succeeds via the grep/sed fallback. it uses the same@requires_bashharness as the existing tests in that file (skips where a suitable bash isn't present).