Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long string in default value causes infinite loop within usage printer #148

Closed
smartboyathome opened this issue Jul 13, 2017 · 3 comments
Closed
Milestone

Comments

@smartboyathome
Copy link

In using picocli version 0.9.7 as part of a Groovy script I am writing, I have uncovered an infinite loop in the usage() printer. Specifically, I have a command line so:

@Command(showDefaultValues = true)
class MainCommand {
    @Option(names = "--config-dir", description = "The path to the directory holding the configs")
    File configDir = Paths.get(getClass().getProtectionDomain().getCodeSource().getLocation().toURI()).getParent().getParent().resolve("configs").toFile()
}

This results in a long path like so: C:\Users\USERNAME\Development\MY_SOFTWARE\my-software-config\configs

This value, after running through break iterator, results in the value of variable text within method CommandLine.Help.TextTable.copy(BreakIterator line, Text text, Text destination, int offset) being \Users\USERNAME\Development\MY_SOFTWARE\my-software-config\configs, which is unable to be wrapped when used by CommandLine.Help.TextTable.putValue(int row, int col, Text value) line 3013. This inability to wrap causes the wrap iterator inside that function to go into an infinite loop.

Now, my workaround is to stop outputting the default value, but I imagine this could bite others as well, but that makes my script less clear.

@remkop
Copy link
Owner

remkop commented Jul 13, 2017

Thanks for reporting this! I haven't looked in detail yet but this is obviously not good.
Do you feel like creating a pull request for this?

@smartboyathome
Copy link
Author

Apologies for the delay, I will see what I can do. What I'm thinking should happen in this case (where a single "word" is larger than the column's maximum width) is that the output should fall back to naive splitting and breaking in the middle of the word. What do you think?

@remkop
Copy link
Owner

remkop commented Jul 18, 2017

Yes, instead of using only BreakIterator.getLineInstance() it should probably fall back to getWordInstance() if the value doesn't fit.

smartboyathome pushed a commit to smartboyathome/picocli that referenced this issue Jul 19, 2017
Splits the word naively at the column boundary.
remkop added a commit that referenced this issue Jul 21, 2017
@remkop remkop added this to the 0.9.8 milestone Jul 21, 2017
remkop added a commit that referenced this issue Jul 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants