The idea there is to preprocess the arguments and change each --context to -C which getopts can then process? I suppose that would work, but note that GNU-style long options can also take arguments in the format --context=foobar, and your construct here doesn't support that. The user would need to know that this particular tool here requires --context foobar as two distinct arguments. Or you'd need to make the preprocessing more complex.

But I wonder whether the use of set -- "${aggr[@]}" is correct.

Or is the following (using eval) more appropriate?

set -- "${aggr[@]}" expands the elements of the array, to distinct words, and then assigns those words to the positional parameters. Each array element will become exactly one positional parameter, without changes.

eval set -- "${aggr[@]}" would expand all the elements of the array, then join them together with spaces, prepend the set -- and evaluate the result as a shell command. That is, if you have the array elements abc def, $(date >&2), ghi'jkl, the command would be

set -- abc def $(date >&2) ghi'jkl 

which would end up with abc and def as two distinct parameters, and it would print the date to stderr, except that the lone single quote will cause a syntax error.

Using eval would be appropriate if you have something that's designed to produce output that's quoted for shell input.

If you're on Linux (and don't care about portability), you could do what roaima suggested in the comments, and use the util-linux version of getopt (without the s). It supports long options too, there's answers showing how to use it in getopt, getopts or manual parsing - what to use when I want to support both short and long options? and in this SO answer and also my answer here.

Incidentally, with that getopt, you would use eval, since as a command, it's limited to producing just a single string as output, not a list like an array.

The idea there is to preprocess the arguments and change each --context to -C which getopts can then process? I suppose that would work, but note that GNU-style long options can also take arguments in the format --context=foobar, and your construct here doesn't support that. The user would need to know that this particular tool here requires --context foobar as two distinct arguments. Or you'd need to make the preprocessing more complex.

You might also want to check all arguments that start with --, as otherwise e.g. a mistyped --cotnext would go to getopts as-is, and you'd get complaints about unknown options. (Or worse, wrong options would be enabled.)

But I wonder whether the use of set -- "${aggr[@]}" is correct.

Or is the following (using eval) more appropriate?

set -- "${aggr[@]}" expands the elements of the array, to distinct words, and then assigns those words to the positional parameters. Each array element will become exactly one positional parameter, without changes.

eval set -- "${aggr[@]}" would expand all the elements of the array, then join them together with spaces, prepend the set -- and evaluate the result as a shell command. That is, if you have the array elements abc def, $(date >&2), ghi'jkl, the command would be

set -- abc def $(date >&2) ghi'jkl 

which would end up with abc and def as two distinct parameters, and it would print the date to stderr, except that the lone single quote will cause a syntax error.

Using eval would be appropriate if you have something that's designed to produce output that's quoted for shell input.

If you're on Linux (and don't care about portability), you could do what roaima suggested in the comments, and use the util-linux version of getopt (without the s). It supports long options too, there's answers showing how to use it in getopt, getopts or manual parsing - what to use when I want to support both short and long options? and in this SO answer and also my answer here.

Incidentally, with that getopt, you would use eval, since as a command, it's limited to producing just a single string as output, not a list like an array, so it uses shell quoting to work around the issue.

The idea there is to preprocess the arguments and change each --context to -C which getopts can then process? I suppose that would work, but note that GNU-style long options can also take arguments in the format --context=foobar, and your construct here doesn't support that. The user would need to know that this particular tool here requires --context foobar as two distinct arguments. Or you'd need to make the preprocessing more complex.

But I wonder whether the use of set -- "${aggr[@]}" is correct.

Or is the following (using eval) more appropriate?

set -- "${aggr[@]}" expands the elements of the array, to distinct words, and then assigns those words to the positional parameters. Each array element will become exactly one positional parameter, without changes.

eval set -- "${aggr[@]}" would expand all the elements of the array, then join them together with spaces, prepend the set -- and evaluate the result as a shell command. That is, if you have the array elements abc def, ghi'jkl, $(date >&2), the command would be

set -- abc def ghi'jkl $(date >&2)

which would end up with abc and def as two distinct parameters, and it would print the date to stderr, except that the lone single quote will cause a syntax error.

Using eval would be appropriate if you have something that's designed to produce output that's quoted for shell input.

If you're on Linux (and don't care about portability), you could do what roaima suggested in the comments, and use the util-linux version of getopt (without the s). It supports long options too, there's answers showing how to use it in getopt, getopts or manual parsing - what to use when I want to support both short and long options? and in this SO answer and also my answer here.

Incidentally, with that getopt, you would use eval, since as a command, it's limited to producing just a single string as output, not a list like an array.

The idea there is to preprocess the arguments and change each --context to -C which getopts can then process? I suppose that would work, but note that GNU-style long options can also take arguments in the format --context=foobar, and your construct here doesn't support that. The user would need to know that this particular tool here requires --context foobar as two distinct arguments. Or you'd need to make the preprocessing more complex.

But I wonder whether the use of set -- "${aggr[@]}" is correct.

Or is the following (using eval) more appropriate?

set -- "${aggr[@]}" expands the elements of the array, to distinct words, and then assigns those words to the positional parameters. Each array element will become exactly one positional parameter, without changes.

eval set -- "${aggr[@]}" would expand all the elements of the array, then join them together with spaces, prepend the set -- and evaluate the result as a shell command. That is, if you have the array elements abc def, $(date >&2), ghi'jkl, the command would be

set -- abc def $(date >&2) ghi'jkl 

which would end up with abc and def as two distinct parameters, and it would print the date to stderr, except that the lone single quote will cause a syntax error.

Using eval would be appropriate if you have something that's designed to produce output that's quoted for shell input.

If you're on Linux (and don't care about portability), you could do what roaima suggested in the comments, and use the util-linux version of getopt (without the s). It supports long options too, there's answers showing how to use it in getopt, getopts or manual parsing - what to use when I want to support both short and long options? and in this SO answer and also my answer here.

Incidentally, with that getopt, you would use eval, since as a command, it's limited to producing just a single string as output, not a list like an array.