James Harris <james.harris.1@gmail.com>:

> I read up on getopts but from tests it seems to require that
> switches precede arguments
>

Yes, that's true.

> rather than allowing them to be specified after, so that doesn't
> seem very good, either.
>

The problem with specifying options after non‐option arguments is
that non‐option arguments may take any form:  They even may start
with an "-", that is, look like options even when they aren't
meant to be used as options.

So, if you have some command "some_command" with one non‐option
argument "a" followed by an option "-b"

$ some_command -a -b

and parse the arguments from left to right then there is no way
for "some_command" to investigate that "-a" is to be taken as a
non‐option argument while "-b" is to be taken as an option.

Whereas, when "some_command" expects options before any
non‐option argument and recognizes the end‐of‐options marker
("--") then there is no ambiguity:

$ some_command -b -- -a

"-b" is an option, while "-a" (because the series of options is
terminated by the end‐of‐options marker) is the (first)
non‐option argument "-a".

That's the way how the POSIX‐shell builtin "getopts" works.