-
Notifications
You must be signed in to change notification settings - Fork 145
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
Getopts or Case for options? #784
Comments
I vote to stay with CASE as we are already with case all over the place. Changing now could make it confusing. I like consistency |
That's where I'm leaning towards. I like getopts for what it allows, but it's not a necessity. |
I also vote to stay with Regards! |
Cool. Here is a snippet I built to work for things like "-fsr" or any number of arts with case.
|
The above snippet seems to handle short options well and looks consistent with the existing code, just a little cosmetic change I would make is to change the variable Regards! |
Will do. I've update PR #783 with this now. |
@bmac2 @yaazkal @JRGTH
I have read many programs that use "while getopts" for their option handling. I notice also that bastille uses mostly "case" for its options.
With the former, we are able to bunch options together like "-fsm" wile with the latter this is not possible unless we add more case blocks.
With the latter, we have the ability to add "long options" like "--force" in addition to "-f".
I'd like to know if we should stay with "case" or perhaps consider integrating "getopt" as the option handler.
Thanks.
The text was updated successfully, but these errors were encountered: