Comment 9 for bug 1722564

Yeah that feels like a premature optomization as that limits your interface options significantly (to only 9 valid choices). I'm suprised there haven't been any other bugs related to this, but maybe there aren't a lot of cli use-cases out there with complex bug-reporting choices.
I've attached a branch that now readlines instance or read(1) for prompts which contain a large set of choices (> 10).

This merge proposal a bit more flexible as it'd also permit options where > 99 choices are presented. I would think that > 99 choices would be a usability issues as I can't fathom people reading through 100+ separate options to actually choose the one that best applies to them.

I'm not sure the SRU team understood the impact of the branch. Per the pastebin that I provided originally, the user wouldn't have to input "3 " they would input "3<enter>" or "1<enter>" or "11".

I've since changes this branch to read until <enter> for all choices if the # or choices are > 10. This means that all existing apport use-cases retain the optimized 1 character choice selection if their provided choices are <= 9. For any lists larger than that (which is currently broken in apport) the user will have to hit enter after their choice.