All three scripts under host-setup/linux/ document their actions as:
Actions, the last one given wins, default --report:
and implement it by overwriting MODE in the arg loop:
-r | --report) MODE="report" ;;
-i | --install) MODE="install" ;;
That silently discards an intent. install-tools.sh --report --install installs a host the operator asked to look at first, and the run says nothing about the --report it dropped. The failure is quiet in the direction that matters: the discarded action is the safe one and the surviving action is the one that changes the host.
Refusing is the better answer, and it is cheap:
ACTIONS=()
-r | --report) ACTIONS+=(report) ;;
...
((${#ACTIONS[@]} <= 1)) || die "More than one action given (${ACTIONS[*]}), name one"Nothing in the repo relies on last-wins. No documented example passes two actions, bootstrap.sh passes exactly one action per run_tool call, and no test asserts the behavior.
The new Windows tooling in host-setup/windows/ already refuses this way and documents Actions, name one. That started as a constraint, since a PowerShell param() block records which switches were given and not the order they came in, so last-wins is not expressible there. But the constraint produced the better behavior, which is why this is filed rather than recorded as a permanent divergence in the Windows README's differences table.
Scope: the three usage() heredocs and the three parse_args() bodies. Once done, the differences table row that currently reads "Actions, the last one given wins | Actions, name one" is deleted rather than kept.
All three scripts under
host-setup/linux/document their actions as:and implement it by overwriting
MODEin the arg loop:That silently discards an intent.
install-tools.sh --report --installinstalls a host the operator asked to look at first, and the run says nothing about the--reportit dropped. The failure is quiet in the direction that matters: the discarded action is the safe one and the surviving action is the one that changes the host.Refusing is the better answer, and it is cheap:
Nothing in the repo relies on last-wins. No documented example passes two actions,
bootstrap.shpasses exactly one action perrun_toolcall, and no test asserts the behavior.The new Windows tooling in
host-setup/windows/already refuses this way and documentsActions, name one. That started as a constraint, since a PowerShellparam()block records which switches were given and not the order they came in, so last-wins is not expressible there. But the constraint produced the better behavior, which is why this is filed rather than recorded as a permanent divergence in the Windows README's differences table.Scope: the three
usage()heredocs and the threeparse_args()bodies. Once done, the differences table row that currently reads "Actions, the last one given wins | Actions, name one" is deleted rather than kept.