-
-
Notifications
You must be signed in to change notification settings - Fork 118
fix: Windows batch file line endings to avoid cmd parsing bug #1222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Windows batch file line endings to avoid cmd parsing bug #1222
Conversation
e90e6c4 to
e7c03d2
Compare
|
e7c03d2 to
bd509fd
Compare
fmeum
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, that's a subtle bug. Thanks for working on a workaround!
09bbce4 to
fd8897e
Compare
|
Anyone from the maintainers or recent merge authors (e.g., @alexeagle @hofbi) able to review this? |
tokup
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice - thanks
Windows cmd has a known bug where GOTO/CALL to labels fails when batch files use LF-only line endings and the label crosses a 512-byte boundary during parsing. This causes "cannot find batch label" errors. References: - https://www.dostips.com/forum/viewtopic.php?t=8988 - rocq-prover/rocq#8610 This fix ensures all generated .bat files use CRLF line endings by converting templates and using \r\n in string replacements throughout: - diff_test: template and substitutions, - write_source_file: batch updater scripts, - windows_utils: native launcher scripts. To verify these changes work correctly across platforms, we add a Go binary (`check_newlines`) that validates line endings: - on Windows: verifies scripts have proper CRLF line endings, - otherwise: verifies \n to \r\n replacements don't affect POSIX scripts. Note: we initially considered `sh_test` with PowerShell/batch wrappers, but encountered issues with interpreter dependencies, script portability, and symlink handling across platforms. A single Go binary invoked via `native_test` proved more reliable and maintainable, working consistently across all platforms (no new external dependencies either).
Address review feedback to use `splitlines()` instead of `split("\n")`
and `replace("\n", "\r\n")` which could produce `\r\r\n` if input
already contains `\r\n`.
`splitlines` properly handles all line ending types (`\n`, `\r\n`, `\r`)
and avoids double-escaping issues.
fd8897e to
60a159e
Compare

Windows cmd has a known bug where GOTO/CALL to labels fails when batch files use LF-only line endings and the label crosses a 512-byte boundary during parsing. This causes "cannot find batch label" errors like, for
diff_test:References:
This fix ensures all generated .bat files use CRLF line endings by converting templates and using \r\n in string replacements throughout:
To verify these changes work correctly across platforms, we add a Go binary (
check_newlines) that validates line endings:Note: we initially considered
sh_testwith PowerShell/batch wrappers, but encountered issues with interpreter dependencies, script portability, and symlink handling across platforms.A single Go binary invoked via
native_testproved more reliable and maintainable, working consistently across all platforms (no new external dependencies either).