You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm often writing scripts that require some parameters to be provided when calling the script, while others are (and that seems to be the reasonable standard when using getoptions) completely (or conditionally – but that's to complicated here) optional. Even when using this super tool here, I am forced to check for the existence of my mandatory parameters after the parsing.
Could it be possible, to include this kind of simple mandatory check into this tool? (Maybe with a new annotation required, or a new type paramReq or so?)
If it could be automatically reflected by the generated options list would be a perfect bonus.
To demonstrate what I mean:
script.sh -a <valueA> [ -b <valueB> ]
This definition would not only require the existence of a value for <valueA> when calling with -a, but the existence of the parameter -a itself.
So the following calls would be correct:
script.sh -a ABCD
script.sh -a ABCD -b 1234
The following would be rejected by getoptions now (assuming that -a and -b configured as params):
script.sh -a
But this would be accepted (by now) also, despite the fact that I want to require the user to provide the -a flag:
script.sh
script.sh -c 1234
As a bonus this kind of "mandatory parameters" could be (optionally) visually be hinted by a small asterisk or some other little character, like so:
My script does the following …
OPTION DESCRIPTION
-a * -- 'My mandatory param a'
-b -- 'My normal/optional param b'
-c -- 'and so on …'
The text was updated successfully, but these errors were encountered:
Another, maybe less intrusive possibility would be to add another (setup-like) keyword like mand to simply check the listed variables to be not-null after the parsing. (In this case, the automatic visual hinting wouldn't be possible anymore, but that's no problem).
As an example (mind the last two configuration lines):
I'm often writing scripts that require some parameters to be provided when calling the script, while others are (and that seems to be the reasonable standard when using
getoptions
) completely (or conditionally – but that's to complicated here) optional. Even when using this super tool here, I am forced to check for the existence of my mandatory parameters after the parsing.Could it be possible, to include this kind of simple mandatory check into this tool? (Maybe with a new annotation
required
, or a new typeparamReq
or so?)If it could be automatically reflected by the generated options list would be a perfect bonus.
To demonstrate what I mean:
This definition would not only require the existence of a value for
<valueA>
when calling with-a
, but the existence of the parameter-a
itself.So the following calls would be correct:
The following would be rejected by
getoptions
now (assuming that-a
and-b
configured asparams
):But this would be accepted (by now) also, despite the fact that I want to require the user to provide the
-a
flag:As a bonus this kind of "mandatory parameters" could be (optionally) visually be hinted by a small asterisk or some other little character, like so:
The text was updated successfully, but these errors were encountered: