Parse Function Arguments as well as Command Arguments #53
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The basic getoptions is designed for use with shell scripts but is not fully compatible for use with functions. The generated parser initializes the parameters in the outer shell rather than inside the parser function. This is ok for shell scripts, but unnecessarily pollutes the shell variables. It is a leaky abstraction.
The intent is for the parent function for which we are generating a parser to declare and bound the scope of the function parameters. Since they are only initialized rather than declared in the generated parser this will prevent pollution of the shell space.
This does not impact command scripts since the initialized variables will have shell global scope anyway, and will therefore be available to the calling script.
The change is actually a one liner moving the start of the generated parser function before the initialization of the variables.
The example shows how to use the modified getoptions to parse function arguments. It generates the parser a single time in a lazy load manner the first time the function is called.