[GH-ISSUE #997] Supplying default "Y" -> answering "yn" means "y" #791

New issue

Closed

opened 2026-02-27 02:53:31 +03:00 by kerem · 4 comments

kerem commented

2026-02-27 02:53:31 +03:00

Owner

Originally created by @TamaMcGlinn on GitHub (Aug 11, 2016).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/997

The normal convention for commandline tools is to ask "Y/n", and you have to enter either Y or n. It seems that LGSM supplies y already, meaning you only have to press enter. However, a new user can easily overlook this, reading "was the install successful ..." I don't even look to see that y is already filled in for me, as my eye skips over the pattern [Y/n]. A fix would be to add, say, 4 spaces after ] and before the "y" that is my default answer.

The result when I look back is that LGSM accepted this:

Was the install successful? [Y/n]yn

to mean "yes". So another fix I would suggest is to check for that answer and make that mean "n", or to make it request clarfication if the answer is not "y" or "n".

Originally created by @TamaMcGlinn on GitHub (Aug 11, 2016). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/997 The normal convention for commandline tools is to ask "Y/n", and you have to enter either Y or n. It seems that LGSM supplies y already, meaning you only have to press enter. However, a new user can easily overlook this, reading "was the install successful ..." I don't even look to see that y is already filled in for me, as my eye skips over the pattern [Y/n]. A fix would be to add, say, 4 spaces after ] and before the "y" that is my default answer. The result when I look back is that LGSM accepted this: `Was the install successful? [Y/n]yn` to mean "yes". So another fix I would suggest is to check for that answer and make that mean "n", or to make it request clarfication if the answer is not "y" or "n".

kerem

2026-02-27 02:53:31 +03:00

closed this issue
added the
type: feature
label

kerem commented

2026-02-27 02:53:32 +03:00

Author

Owner

@jaredballou commented on GitHub (Aug 18, 2016):

My take here is that the whole user input thing needs to be refactored. There ought to be a new function for user input, which will let us better handle errors and conditions in a central location, rather than needing to validate and mess with each separate value. I've been batting around an idea for handling input which I will post as a new issue presently.

@jaredballou commented on GitHub (Aug 18, 2016): My take here is that the whole user input thing needs to be refactored. There ought to be a new function for user input, which will let us better handle errors and conditions in a central location, rather than needing to validate and mess with each separate value. I've been batting around an idea for handling input which I will post as a new issue presently.

kerem commented

2026-02-27 02:53:32 +03:00

Author

Owner

@UltimateByte commented on GitHub (Feb 9, 2017):

Interesting remark from @s-eam

The Y/N prompts can be different in certain aspects (e.g., character case, spacing, and initial text) than those found in other CLI programs. This difference may make LGSM less intuitive for new users.

For my part, i'd love to see some standardized prompts in core_messages.sh.

@UltimateByte commented on GitHub (Feb 9, 2017): Interesting remark from @s-eam > The Y/N prompts can be different in certain aspects (e.g., character case, spacing, and initial text) than those found in other CLI programs. This difference may make LGSM less intuitive for new users. For my part, i'd love to see some standardized prompts in core_messages.sh.

kerem commented

2026-02-27 02:53:32 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Feb 19, 2017):

a standard prompt has now been created and is in the develop branch ready for next release

@dgibbs64 commented on GitHub (Feb 19, 2017): a standard prompt has now been created and is in the develop branch ready for next release

kerem commented

2026-02-27 02:53:32 +03:00

Author

Owner

@lock[bot] commented on GitHub (Jul 18, 2018):

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock[bot] commented on GitHub (Jul 18, 2018): This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

kerem referenced this issue

2026-02-27 03:53:34 +03:00

[PR #791] [MERGED] Support for branch added #3180