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
That all works great, but then I need to do something like this for the remaining positional arguments:
parse_args() {
local var_names=("$@")
local i=0
forargin$ARGS;doechoexport${var_names[$i]}="$arg"
i=$((i +1))done
}
eval"$(parse_args "FIRST""SECOND")"echo$FIRST# outputs "first_arg"echo$SECOND# outputs "second_arg"
Do you think it makes sense to add a new kind of argument to the parser_definition where I can define the positional arguments too? Maybe something along these lines:
I imagine that this could filter $@ to elements that do not begin with a - or --, and then $MY_ARG is assigned the value of the first arg, $ANOTHER_ARG is assigned the value of the second arg, and so forth.
There are probably other considerations for this library, but as a starting point, does this idea make sense and/or would you be interested in a PR to add something like that?
The text was updated successfully, but these errors were encountered:
Right. I'm saying that it would be nicer if the positional args could be defined in the same parser definition function (and have the positional args loaded into the right vars), rather than doing extra stuff after calling __parse
I have a command that can be invoked like so:
(first_arg and second_arg are arbitrary strings)
My parser definition looks like this:
That all works great, but then I need to do something like this for the remaining positional arguments:
Do you think it makes sense to add a new kind of argument to the parser_definition where I can define the positional arguments too? Maybe something along these lines:
parser_definition() { setup ARGS param FOO --foo arg MY_ARG arg ANOTHER_ARG }
I imagine that this could filter $@ to elements that do not begin with a
-
or--
, and then $MY_ARG is assigned the value of the first arg, $ANOTHER_ARG is assigned the value of the second arg, and so forth.There are probably other considerations for this library, but as a starting point, does this idea make sense and/or would you be interested in a PR to add something like that?
The text was updated successfully, but these errors were encountered: