18 ms·
> Heh, was that an attempt at sarcasm? There was definitely a wink component, but at the same time, I meant it. Half the code is just case / esac syntax, whic
by neuromanser 3y ago
> Heh, was that an attempt at sarcasm?
There was definitely a wink component, but at the same time, I meant it.
Half the code is just case / esac syntax, which you can (i do) find plenty use for outside of getopts. getopts itself is… manageable. In the end, the code is such a strong pattern, it's basically a snippet. The lack of variation is what makes it kinda easy to remember. Or you could put it in your notes or a gist and copy/paste.
> That's super difficult to do from memory, at least for me. Maybe I'm not as good at memorizing things as you are.
Nah, my memory is shot. It's a matter of practice, and not being shy with man pages. Use it often enough, it's in memory; after a long hiatus, the details are a "/^\s*getopts \[" away (assuming your man pager is less).
- kazinator 3y agoI find it's much better to have a copy-pasted piece of code which turns all command line options into variables in a certain namespace (provided the variables are defined beforehand) I.e. user runs: script --foo --bar=yes --no-xyzzy --uiuez" the script then sets these existing variables: opt_foo=y opt_foo_given=y opt_bar=y opt_bar_given=y opt_xyzzy= opt_xyzzy_given=y However, the variable opt_uiuez doesn't exist and so it bails: script: no such option: --uiuez With such a piece of code, all you do is define the options you support via assignments like "opt_foo=". You can give them default values this way. Include that piece of boiler-plate code. Done. To add a new option, just define the variable. Done. Check its value wherever needed, and possibly the _given, if the code needs to know whether it's working with the default value, or an explicitly given value. That's it.