Use OS-dependent line ending for generated messages
bengtmartensson opened this issue · comments
Per convention, a well-behaved Java program should generate text in the native format for the platform it runs on, i.e. lines ended by \r\n on Windows, \r on Mac, \n on others. JCommander does not do that when generating error/usage messages, but has \n hard-soldered in. (14 occurrences in DefaultUsageFormatter, JCommander and UnixStyleUsageFormatter.)
The system dependent line separator is available as System.getProperty("line.separator"). I suggest this to be used instead of "\n". On request, I will be happy to submit a PR.
Feel free to provide a PR. BTW, besides line.separator there is %n when using printf.
Actuallly I have quickly executed a JCommander-based application on Windows and the --help output was printed just fine in multiple lines. So I in fact cannot see that there actually is a bug. Can you please proof your claim?
Have a look at DefaultUsageFormatterTest.testOutputFormat(), the String expected. There the desired output is set to contain "\n" as line separators, independent on OS. (You may call it a "specification error" rather than an implementation error.)
Actuallly I have quickly executed a JCommander-based application on Windows and the --help output was printed just fine in multiple lines.
Not very much of a proof of correct behavior. Somehow the Windows text console manages to handle Unix-formatted text sensibly.
@bengtmartensson Please provide a proof that JCommander actually fails on an operating system. As "somehow" the bug seems to go away, there is no need to change the software.
Some simple text editors (textedit?) on Windows/MSDOS cannot render Unix text correctly -- at least this was the case in the past.
The official text format on Windows/MSDOS is with "\r\n" as line separator. To generate text in Unix format on Windows is an error -- even if many utilities there groks it.
On sleeping on the issue it struck me that there is a substantial risk that "something" depends on the old behavior. This library is reasonably well spread (1900 stars), so we should be careful with possibly incompatible changes. I will therefore revoke and close the issue. I can live with the "quirk".
On sleeping on the issue it struck me that there is a substantial risk that "something" depends on the old behavior. This library is reasonably well spread (1900 stars), so we should be careful with possibly incompatible changes. I will therefore revoke and close the issue. I can live with the "quirk".
Aren't breaking releases meant to accomplish this? The argument of usage may prevent further innovation in the future as the same argument will apply at the time as well
Assuming that this is a real reproducible problem, the library should do its best to be correct and platform independent
Unless somebody confirms that he can reproduce the problem on a real operating system CLI this is not considered to be an existing problem.