@georglauterbach @polarathene
See my second commit 7a4186f. Any idea why this was implemented this way in the first place?

If you agree, I'll change this logic in the other files as well.

See my second commit 7a4186f.

More strict handling of the password parameter.
After shift, $* considers not only the first parameter, but all as password.
setup email add foo@example.com top secret makes "topsecret" the password, which is weird.

Any idea why this was implemented this way in the first place?

I cannot recall, the scripts for all of these features was inconsistent and messy (Not that the unified approach I refactored is any more pleasant to work with). It was probably a naive approach. If someone wants spaces they should quote wrap, no clue why we'd take in additional parameters, I think some utilities did have sanity checks on parameter length.

This is really something that'd be much nicer in Rust or similar instead of the assortment of shell scripts and awkward syntax required for some of the logic which is not as nice to maintain.

If there was a reason for it that isn't obvious and we break something by removing the shift logic, then we revert and add test cases 😅

I assume the shift was used for the convenience of passing remaining params to a function call with ${@}? I haven't looked at those scripts in some time.

The reference issue this is a fix for I think was more of a UX error with the omission of a password, there is no prompt provided as context for "Enter a password" (there is in the script... but not in their output of the bug report? 🤷‍♂️ )

I don't know either why we use ${*}, ${2} seems more appropriate 👍🏼