From 92f2ff368d2ce0512725c7dd498f40a0ca38ceab Mon Sep 17 00:00:00 2001 From: DonislawDev Date: Wed, 2 Sep 2026 14:58:14 +0200 Subject: [PATCH 1/2] docs: a PowerShell script needs one more line, or a failed run reports success Measured on 2026-09-02, in both Windows PowerShell 5.1 and pwsh 7: tfg with a bad flag returns 2 when it is run directly, and the same call wrapped in a .ps1 run with -File makes the script answer 0. Adding exit $LASTEXITCODE brings the 2 back. That is PowerShell rather than this tool - a script does not inherit the exit code of the last program it ran. But .ps1 is the ordinary wrapper on Windows, and this tool is meant to be wired into CI, so a person following the exit code table would get a green build on a run that refused the work. The CI section now says so and shows the line. cmd, bash and zsh need nothing. Co-Authored-By: Claude Opus 5 --- README.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/README.md b/README.md index ee745a3..31c22ea 100644 --- a/README.md +++ b/README.md @@ -590,6 +590,21 @@ An invalid recipe writes **no files at all** and reports every problem at once, each naming the setting it is about. A run stopped with Ctrl+C still leaves a manifest, and never leaves a half written file behind. +### A PowerShell script needs one more line + +PowerShell does not carry the exit code of a program out of a `.ps1` file. Run +one with `-File` and the script answers `0` even when the tool inside refused +the work, so a build that should be red goes green: + +```powershell +tfg generate fixtures.yaml --out ./fixtures +exit $LASTEXITCODE +``` + +That last line is the whole of it. This is how PowerShell behaves rather than +anything about this tool, which returns the code from the table above either +way. `cmd`, `bash` and `zsh` need nothing extra. + ## ❓ Questions ### How is this different from `dd`, `fsutil` or `truncate`? From 6493ca034e1697fd92796e9560dc3aec12aecf84 Mon Sep 17 00:00:00 2001 From: DonislawDev Date: Wed, 2 Sep 2026 15:12:02 +0200 Subject: [PATCH 2/2] docs: a relative output.dir is read from where you run, not from the recipe Measured on 2026-09-02: a recipe kept in recipes/ with dir: out, run from somewhere else, writes into out beside the caller rather than beside the recipe. The behaviour has been the same since the beginning and was written down nowhere, so the first person keeping recipes in their own directory had to find it by looking for the files. The key table now says it, with the way to pin it down. Co-Authored-By: Claude Opus 5 --- README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 31c22ea..4e741fb 100644 --- a/README.md +++ b/README.md @@ -377,9 +377,12 @@ tfg generate fixtures.yaml | `seed` | the number that makes a run repeatable. Same seed, same bytes | | `defaults.label` | write the self describing label inside each file. Default `true` | | `targets` | the list of things to produce. See below | -| `output.dir` | where the files and the manifest go | +| `output.dir` | where the files and the manifest go. A relative path is read from the directory you run in, not from the one the recipe sits in | | `output.manifest` | manifest file name. Default `manifest.json` | +So a recipe kept in `recipes/` with `dir: out` writes into `out` next to you, not +next to the recipe. Give an absolute path, or `--out`, when you want it fixed. + ### Target keys | key | meaning |