fix: Windows batch file line endings to avoid cmd parsing bug by rdesgroppes · Pull Request #1222 · bazel-contrib/bazel-lib

rdesgroppes · 2025-12-19T23:42:14Z

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:

The system cannot find the batch label specified - compare_files

References:

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).

aspect-workflows · 2025-12-19T23:46:25Z

Bazel 8 (Test)

4 test targets passed

Targets

//lib/tests/copy_to_directory:case_22_test [k8-fastbuild]                                                 115ms
//lib/tests/copy_to_directory_bin_action:test [k8-fastbuild]                                              102ms
//lib/tests/write_source_files:write_source_file_script_newlines_test [k8-fastbuild]                      85ms
//lib/tests/write_source_files:write_source_file_test_script_newlines_test [k8-fastbuild]                 80ms

Total test execution time was 382ms. 131 tests (97.0%) were fully cached saving 42s.

Bazel 9 (Test)

4 test targets passed

Targets

//lib/tests/copy_to_directory:case_22_test [k8-fastbuild]                                                 130ms
//lib/tests/copy_to_directory_bin_action:test [k8-fastbuild]                                              77ms
//lib/tests/write_source_files:write_source_file_script_newlines_test [k8-fastbuild]                      124ms
//lib/tests/write_source_files:write_source_file_test_script_newlines_test [k8-fastbuild]                 121ms

Total test execution time was 452ms. 131 tests (97.0%) were fully cached saving 25s.

Bazel 7 (Test)

e2e/api_entries

All tests were cache hits

1 test (100.0%) was fully cached saving 23ms.

Bazel 8 (Test)

e2e/api_entries

All tests were cache hits

1 test (100.0%) was fully cached saving 23ms.

Bazel 9 (Test)

e2e/api_entries

All tests were cache hits

1 test (100.0%) was fully cached saving 31ms.

Bazel 7 (Test)

e2e/copy_action

All tests were cache hits

1 test (100.0%) was fully cached saving 20ms.

Bazel 8 (Test)

e2e/copy_action

All tests were cache hits

1 test (100.0%) was fully cached saving 21ms.

Bazel 9 (Test)

e2e/copy_action

All tests were cache hits

1 test (100.0%) was fully cached saving 33ms.

Bazel 7 (Test)

e2e/copy_to_directory

All tests were cache hits

6 tests (100.0%) were fully cached saving 309ms.

Bazel 8 (Test)

e2e/copy_to_directory

All tests were cache hits

6 tests (100.0%) were fully cached saving 295ms.

Bazel 9 (Test)

e2e/copy_to_directory

All tests were cache hits

6 tests (100.0%) were fully cached saving 263ms.

Bazel 7 (Test)

e2e/coreutils

All tests were cache hits

4 tests (100.0%) were fully cached saving 204ms.

Bazel 8 (Test)

e2e/coreutils

All tests were cache hits

4 tests (100.0%) were fully cached saving 260ms.

Bazel 9 (Test)

e2e/coreutils

All tests were cache hits

4 tests (100.0%) were fully cached saving 271ms.

Bazel 7 (Test)

e2e/external_copy_to_directory

All tests were cache hits

1 test (100.0%) was fully cached saving 20ms.

Bazel 8 (Test)

e2e/external_copy_to_directory

All tests were cache hits

1 test (100.0%) was fully cached saving 21ms.

Bazel 9 (Test)

e2e/external_copy_to_directory

All tests were cache hits

1 test (100.0%) was fully cached saving 33ms.

Bazel 7 (Test)

e2e/smoke

All tests were cache hits

4 tests (100.0%) were fully cached saving 415ms.

Bazel 8 (Test)

e2e/smoke

All tests were cache hits

4 tests (100.0%) were fully cached saving 636ms.

Bazel 9 (Test)

e2e/smoke

All tests were cache hits

4 tests (100.0%) were fully cached saving 732ms.

Bazel 7 (Test)

e2e/write_source_files

All tests were cache hits

1 test (100.0%) was fully cached saving 30ms.

Bazel 8 (Test)

e2e/write_source_files

All tests were cache hits

1 test (100.0%) was fully cached saving 28ms.

Bazel 9 (Test)

e2e/write_source_files

All tests were cache hits

1 test (100.0%) was fully cached saving 35ms.

fmeum

Wow, that's a subtle bug. Thanks for working on a workaround!

lib/private/write_source_file.bzl

rdesgroppes · 2026-01-09T17:22:04Z

Anyone from the maintainers or recent merge authors (e.g., @alexeagle @hofbi) able to review this?

tokup

Very nice - thanks

lib/private/diff_test.bzl

lib/private/write_source_file.bzl

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.

This upgrade includes a Windows compatibility fix for batch file line endings (bazel-contrib/bazel-lib#1222), which resolves a cmd parsing bug where GOTO/CALL to labels fails when batch files use non CRLF-only line endings and a label crosses a 512-byte boundary: ```diff $ bazel test //deps/openssl3:module_consistency_test [...] ==================== Test output for //deps/openssl3:module_consistency_test: -The system cannot find the batch label specified - compare_files +compare_files +FAIL: files "C:\[...]\bazel-out\[...]\deps\openssl3\openssl3.MODULE.bazel.new" and "C:\[workspace]\deps\openssl3\openssl3.MODULE.bazel" differ. + + +@@//deps/openssl3:openssl3.MODULE.bazel is out of date. To update this file, run: + + bazel run //deps/openssl3:module_consistency +To see differences run: + + diff "C:\[...]\bazel-out\[...]\deps\openssl3\openssl3.MODULE.bazel.new" "C:\[workspace]\deps\openssl3\openssl3.MODULE.bazel" + ================================================================================ ``` Because this now surfaces we'd been generating `*.MODULE.bazel` with OS-specific newlines, the present change fixes it by always issuing UNIX-style newlines: ```sh $ bazel test //deps/openssl3:module_consistency_test [...] //deps/openssl3:module_consistency_test PASSED in 0.4s ``` `bazel_lib` 3.1.1 comes with further improvements, like: - bazel-contrib/bazel-lib#1217 - bazel-contrib/bazel-lib#1220 - bazel-contrib/bazel-lib#1232

### What does this PR do? This upgrade includes a Windows compatibility fix for batch file line endings (bazel-contrib/bazel-lib#1222), which resolves a cmd parsing bug where GOTO/CALL to labels fails when batch files use non CRLF-only line endings and a label crosses a 512-byte boundary: ```diff > bazel test //deps/openssl3:module_consistency_test [...] ==================== Test output for //deps/openssl3:module_consistency_test: -The system cannot find the batch label specified - compare_files +compare_files +FAIL: files "C:\[...]\bazel-out\[...]\deps\openssl3\openssl3.MODULE.bazel.new" and "C:\[workspace]\deps\openssl3\openssl3.MODULE.bazel" differ. + + +@@//deps/openssl3:openssl3.MODULE.bazel is out of date. To update this file, run: + + bazel run //deps/openssl3:module_consistency +To see differences run: + + diff "C:\[...]\bazel-out\[...]\deps\openssl3\openssl3.MODULE.bazel.new" "C:\[workspace]\deps\openssl3\openssl3.MODULE.bazel" + ================================================================================ ``` Because this now surfaces we'd been generating `*.MODULE.bazel` with OS-specific newlines, the present change fixes it by always issuing UNIX-style newlines: ``` > bazel test //deps/openssl3:module_consistency_test [...] //deps/openssl3:module_consistency_test PASSED in 0.4s ``` ### Motivation Keep up to date and better support colleagues working on Windows. ### Describe how you validated your changes Locally for the time being because we still have very limited test coverage due to #44455 being disputed. ### Additional Notes `bazel_lib` 3.1.0/3.1.1 comes with further improvements, like: - bazel-contrib/bazel-lib#1217 - bazel-contrib/bazel-lib#1220 - bazel-contrib/bazel-lib#1232 Co-authored-by: regis.desgroppes <[email protected]>

rdesgroppes changed the title ~~Fix Windows batch file line endings to avoid cmd.exe parsing bug~~ Fix Windows batch file line endings to avoid cmd parsing bug Dec 19, 2025

rdesgroppes changed the title ~~Fix Windows batch file line endings to avoid cmd parsing bug~~ fix: Windows batch file line endings to avoid cmd parsing bug Dec 19, 2025

rdesgroppes force-pushed the fix-diff-test-line-endings-on-windows branch from e90e6c4 to e7c03d2 Compare December 19, 2025 23:44

rdesgroppes force-pushed the fix-diff-test-line-endings-on-windows branch from e7c03d2 to bd509fd Compare December 19, 2025 23:47

fmeum reviewed Dec 20, 2025

View reviewed changes

lib/private/write_source_file.bzl Outdated Show resolved Hide resolved

rdesgroppes force-pushed the fix-diff-test-line-endings-on-windows branch 6 times, most recently from 09bbce4 to fd8897e Compare January 6, 2026 16:59

rdesgroppes marked this pull request as ready for review January 6, 2026 17:08

rdesgroppes requested a review from fmeum January 6, 2026 17:09

tokup reviewed Jan 11, 2026

View reviewed changes

lib/private/diff_test.bzl Outdated Show resolved Hide resolved

lib/private/write_source_file.bzl Outdated Show resolved Hide resolved

rdesgroppes added 2 commits January 12, 2026 12:08

rdesgroppes force-pushed the fix-diff-test-line-endings-on-windows branch from fd8897e to 60a159e Compare January 12, 2026 12:03

rdesgroppes requested a review from tokup January 12, 2026 12:07

tokup approved these changes Jan 13, 2026

View reviewed changes

fmeum approved these changes Jan 13, 2026

View reviewed changes

fmeum enabled auto-merge (squash) January 13, 2026 16:05

fmeum merged commit 8a8fcd6 into bazel-contrib:main Jan 13, 2026
20 checks passed

rdesgroppes deleted the fix-diff-test-line-endings-on-windows branch January 13, 2026 16:38

tkctec mentioned this pull request Jan 14, 2026

Use windows line endings for batch files #1224

Closed

rdesgroppes mentioned this pull request Jan 19, 2026

Bump bazel_lib from 3.0.1 to 3.1.1 DataDog/datadog-agent#45220

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: Windows batch file line endings to avoid cmd parsing bug#1222

fix: Windows batch file line endings to avoid cmd parsing bug#1222
fmeum merged 2 commits intobazel-contrib:mainfrom
rdesgroppes:fix-diff-test-line-endings-on-windows

rdesgroppes commented Dec 19, 2025 •

edited

Loading

Uh oh!

aspect-workflows bot commented Dec 19, 2025 •

edited

Loading

Uh oh!

fmeum left a comment

Uh oh!

Uh oh!

rdesgroppes commented Jan 9, 2026

Uh oh!

tokup left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

rdesgroppes commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aspect-workflows bot commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

e2e/api_entries

e2e/api_entries

e2e/api_entries

e2e/copy_action

e2e/copy_action

e2e/copy_action

e2e/copy_to_directory

e2e/copy_to_directory

e2e/copy_to_directory

e2e/coreutils

e2e/coreutils

e2e/coreutils

e2e/external_copy_to_directory

e2e/external_copy_to_directory

e2e/external_copy_to_directory

e2e/smoke

e2e/smoke

e2e/smoke

e2e/write_source_files

e2e/write_source_files

e2e/write_source_files

Uh oh!

fmeum left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rdesgroppes commented Jan 9, 2026

Uh oh!

tokup left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rdesgroppes commented Dec 19, 2025 •

edited

Loading

aspect-workflows bot commented Dec 19, 2025 •

edited

Loading