fix(rustup-init/sh): prevent passing --default-host twice

[rami3l]

Follow-up of #4497, closes #4755.

My apologies for having misled you @cachebag on this one (I mistakenly thought rustup followed the GNU coreutils conventions, but should we adopt just that in rustup the binary instead?) 🙇

@abr-egn Please feel free to test the patch locally if you have time 🙏

[ChrisDenton]

Changes look good to me.

I think an argument could be made that rustup should just use the last value passed in. I don't think this is clear cut though and could do with some more discussion. For example, rustc only allows one --target (is that a mistake? is --default-host different? I don't know).

View changes since this review

[rami3l]

I think an argument could be made that rustup should just use the last value passed in.

@ChrisDenton Yeah that's how I did the review 😅 clearly confused rustup with something else; but we could easily revert this if we are going that way.

I'd say I'll merge upon @abr-egn's approval.

[abr-egn]

This does indeed fix it, thanks for the quick update!

View changes since this review

[cachebag]

should we adopt just that in rustup the binary instead?

@rami3l most CLI tools follow this convention of "last flag wins", as @ChrisDenton notes.

we could just take a 'belt and suspenders' approach to this; #[arg(long, overrides_with = "default_host")] in the RustupInit struct and then your fix here is perfect- now the script is covered and so is the binary. I can open a PR for this if you agree.

For example, rustc only allows one --target (is that a mistake? is --default-host different? I don't know).

@ChrisDenton
It's my understanding that rustc disallowing multiple --target is arguably a design choice specific to compilation, where "which target?" is a critical single-answer question. I feel that --default-host in rustup is a configuration preference, and "last wins" is more user-friendly IMHO.