Server Fault Asked by cmcginty on December 13, 2020
I think I ran across a bug in a batch file because it was written with unix line endings. Is this a known problem with cmd.exe running batch files in windows?
This really isn't a "bug"... as it is by-design. Windows new-lines are defined as "rn" ... or a "Carriage Return" and "New Line" combination... whereas *nix flavors prefer omitting the carriage return. You should always use "rn" in anything in Windows where possible. Anything else may be interpreted incorrectly... and cause a great deal of unexpected results.
Correct answer by TheCompWiz on December 13, 2020
The answer is: you may get "lucky" and it will work with LF, but don't count on it. We had same problem as the original requestor. Our process would end up with bat files that were only LF, and (sorry could not find a pattern) sometimes a label would be 'not found', though clearly it was there. Would have to convert to CR-LF, or make random changes until it worked!
Answered by Dave Rock on December 13, 2020
It seems that batch labels are skipped when LF (Unix line-ending) is used in a .bat file.
Answered by go2null on December 13, 2020
For batch files there is no big difference between unix line endings and windows line endings.
Currently, there is only a glitch known for the behavior of GOTO and CALL, while searching for a label. The label parser fails to find a label, if the label is on a 512 byte boundary relative to the current file position. The difference is, because the carriage return is used for an internal line reset. See Call and goto may fail when the batch file has Unix line endings
Despite the label scanner, it's unexpected to find more problems, because the batch parser removes all carriage returns directly after the percent expansion phase.
Answered by jeb on December 13, 2020
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP