15 September 2026
The release build runs as a chain: obfuscate the source, inject the result
into the packaging spec, package it, then hand the output to the installer
compiler. It is a .bat file because every tool in that chain is a
Windows executable.
One day it ran all the way through, produced a working installer, and then failed at the end with a syntax error.
This path:
"C:\Program Files (x86)\..."inside a parenthesised if / else block.
cmd.exe parses a bracketed block by scanning for the closing
parenthesis, and that scan does not fully respect quotes. The )
inside Program Files (x86) gets read as the end of the block. The rest
of the line then makes no sense, and the interpreter says so.
The reason it failed after succeeding is that the broken statement was in the last branch. Everything real had already run. The build was fine; the script reporting on the build was not.
The trap: there is no way to look at that line and see the problem. It is a correct path, correctly quoted, in a correct conditional. The bug is a parser rule from the 1980s that quoting does not save you from.
Get the parenthesised path out of the bracketed block. Assign it to a
variable beforehand and reference the variable inside the block, or restructure
the conditional to use goto labels instead of brackets. Either
works; the point is that the literal never appears between the brackets.
A build script that exits non-zero after doing its job correctly is a special kind of unhelpful, because the obvious conclusion — the build is broken — is false, and acting on it means re-running a long pipeline that was never at fault. If a build step can fail, it should fail before it spends twenty minutes succeeding.