I think we can consider the eval save by passing the elements through printf '%q' first. Sorry, I had used this trick before and since forgotten. It actually makes things simpler in general, I think (no need for tr or messing with $IFS):

safe_example() {
> cat <<'EOM'
> --foo bar
> --baz
> --bat "a hoy"
> EOM
> }

evil_example() {
cat <<'EOM'
> --foo
> $(ls /etc)
> --bar
> EOM
> }

[patrick@leo ops]$ eval "x=( $(safe_example | xargs printf '%q ') )"
[patrick@leo ops]$ printf '>%s<\n' "${x[@]}"
>--foo<
>bar<
>--baz<
>--bat<
>a hoy<

[patrick@leo ops]$ eval "y=( $(evil_example | xargs printf '%q ') )"
[patrick@leo ops]$ printf '>%s<\n' "${y[@]}"
>--foo<
>$(ls<
>/etc)<
>--bar<

Happy to look at that code and see, but I wouldn't consider that possibility and immediate reason to change the implementation.

"The code in the conf will be eval-d" isn't itself a vulnerability. It requires that the code in the conf can somehow be attacker-controlled. And if an attacker can change /etc/downgrade.conf on you, I think you have bigger problems, right?

we just replace test/options_sanity/array_uniqueness.t with your second suggestion?

Sure, SGTM.

I try not to avoid suppressing errors unless there's a reason. If an end-user made a mistake in --pacman-cache, would it be better to show them what find said about it or hide it? I don't know the answer, but that's the question I'd ask.

as we already did in other cases

This is definitely a case-by-case decision IMO, but if you describe the other cases, maybe there is a generally applicable way to decide for this one.

Take it or leave it, but I might say,

# Defaults are shown, uncomment and define values as desired 

I think it would be clearer to organize these tests such that each test case is only testing one thing, and that we do a suite by function. As they are, the unique assertions and parsing assertions are a bit mixed.

test/parse_options.t

Reads multiple --pacman-cache options into PACMAN_CACHE

  $ parse_options --pacman-cache /home/ --pacman-cache /away/ --pacman-cache /home/ foo 2>/dev/null
  > echo "${PACMAN_CACHE[@]}"
  /home/ /away/ /home/

Reads arguments into terms

  $ parse_options foo bar foo 2>/dev/null
  > echo "${terms[@]}";
  foo bar foo

test/read_unique.t

Sets unique arguments into a variable

  $ read_unique X x y y z y z
  > echo "${X[@]}"
  x y z

WDYT?

I agree this is probably the only way to do it. I wonder if there are any security concerns with this here.

What prompted the 2>/dev/null?

:+1:

Automated style fixes for #151, created by Restyled.

The following restylers made fixes:

• shfmt

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

Automated style fixes for #151, created by Restyled.

The following restylers made fixes:

• shfmt

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

Does declare within a function imply local? I have no idea. I would usually do local system_args=().

I also wonder if configuration_args / conf_args is a better name. I'm not sure there's much meaning in "system" yet.

You dropped the "Up-convert older variables", which is fine, but I think would mean a major version bump?

I came up with the following grep -- does it work? I find it easier to reason about, but it could be subjective.

read_downgrade_conf() { grep -E -v '^ *(#.*)?$')  "$DOWNGRADE_ROOT_CONF" 2>/dev/null | xargs; }

read_unique() {
  local var=$1
  shift

  IFS=$'\n' read -r -a var <<<"$(printf "%s\n" "$@" | uniq)"
}

  read_unique terms "${terms[@]}"
  read_unique PACMAN_CACHE "${PACMAN_CACHE[@]}"

Can we add a test suite on this behavior? It's going to be tricky and I'd like to avoid regressions in the future.

I don't think we have any options that accept arguments with spaces in them right now, but if it's not too complicated, I think we should try to write this code to handle that now. In other words:

# Some header comment

# --example option
--actual "Option with spaces"

Should return ["--actual", "Option with spaces"]. I think the code you have would return ["--actual", "Option", "with", "spaces"], right?

Automated style fixes for #151, created by Restyled.

The following restylers made fixes:

• shfmt

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

Automated style fixes for #151, created by Restyled.

The following restylers made fixes:

• shfmt

To incorporate these changes, merge this Pull Request into the original. We recommend using the Squash or Rebase strategies.

NOTE: As work continues on the original Pull Request, this process will re-run and update (force-push) this Pull Request with updated style fixes as necessary. If the style is fixed manually at any point (i.e. this process finds no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

I am thinking of combining points (1) and (2) in this PR, as they seem quite complementary

In any case, I am almost done with coding (1) and now moving on to (2). Am encountering a small issue

Note that there's no need to die release cadence and PR cadence here. Even if you think (1) and (2) should be released in the same version, I'd encourage you to open separate PRs. If (1) is basically done, and you're hitting issues addressing (2), I would prefer reviewing and getting (1) merged so I can focus on (2) in isolation. Unless the code is just so inter-related you don't think that'd be valuable. Up to to you.

As per #144, we made downgrade a root-level operation

Oh geeze, I totally forgot this. I'm actually now on the side that a user-level configuration just doesn't make sense and we shouldn't do it. Is there a really compelling use-case for it?

Alternatively, we could drop (2) and (3) altogether and only permit the use of a single root-level configuration file