Skip to content
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

Mandatory/optional parameters #41

Open
2chg opened this issue Feb 21, 2022 · 1 comment
Open

Mandatory/optional parameters #41

2chg opened this issue Feb 21, 2022 · 1 comment

Comments

@2chg
Copy link

2chg commented Feb 21, 2022

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 …'
@2chg
Copy link
Author

2chg commented Feb 21, 2022

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):

parser_definition() {
    setup   REST error:parse_error help:usage -- \
        "Usage: my_Script.sh -n <name> -p <password> [ -f <firstname> ]" ''
    msg     label:'OPTION' -- 'DESCRIPTION'
    msg     -- ''

    param   LASTNAME      -n  -- 'last name (mandatory)'
    param   PASSWORD      -p  -- 'password (mandatory)'
    param   FIRSTNAME     -f  -- 'first name (optional)'

    mand LASTNAME
    mand PASSWORD
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant