-
Bug
-
Resolution: Fixed
-
Major
-
Windows 2008 Server R2, Enterprise Edition, x64
For a build step of type "Execute Windows batch command" Hudson generates and then executes a .bat file using the content provided by the user in the configuration textbox of the step.
The problem is that the generated .bat file has UNIX style EOL (lines ending with LF) and the Windows Command Interpreter (CMD.EXE) requires Windows style EOLs (lines ending with CR LF) in batches, in order to interpret them correctly.
The consequences of having UNIX style EOL in Windows batches is undetermined. Very simple batches work while more complex ones will behave erratically because CMD.EXE will consume multiple lines in one command and it will fail to find some labels.
- is duplicated by
-
JENKINS-9528 Glitches due to "Execute Windows batch command" being stored with UNIX line endings
-
- Resolved
-
[JENKINS-7478] Wrong EOL (UNIX type: LF) in Windows batch files executed for build steps of type "Execute Windows batch command"
Link |
New:
This issue is duplicated by |
Affects Version/s | New: current [ 10162 ] |
I don't find that this is the case here - in a 100% Windows environment.
I'm not saying that it isn't possible to have this problem, but it isn't universal. My guess is that you'd need a mixed environment with some parts of Hudson working with unix EOLs and some with Windows EOLs.
e.g. Is your Hudson server on a unix machine, with the slave on Windows?
e.g. Or maybe you used a browser on a unix machine and Hudson simply saved the unix-EOLed data "as is"?