search

cbeust / jcommander

Command line parsing framework for Java
Apache License 2.0
1.94k stars 332 forks source link

Use OS-dependent line ending for generated messages #580

Closed bengtmartensson closed 3 months ago

bengtmartensson commented 4 months ago

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.

mkarg commented 4 months ago

Feel free to provide a PR. BTW, besides line.separator there is %n when using printf.

mkarg commented 4 months ago

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?

bengtmartensson commented 4 months ago

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.

mkarg commented 4 months ago

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

bengtmartensson commented 3 months ago

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.

bengtmartensson commented 3 months ago

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

yeikel commented 3 months ago

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

mkarg commented 3 months ago

Unless somebody confirms that he can reproduce the problem on a real operating system CLI this is not considered to be an existing problem.