Working around a weird quirk of getopt

[amete]

While testing out #178, I noticed a "feature" of getopt that confused me for a while. When the user provides a wrong set of arguments, e.g.:

prmon -i 1 foo -- sleep 5

The forked process executes foo instead of sleep. This is because getopt seems to re-order argv and puts all non-option arguments at the end, i.e.:

argv : prmon -i 1 foo -- sleep 5
getopt_long
argv : prmon -i 1 -- foo sleep 5

As a result, we not only silently omit the wrong input but also end up calling the wrong command later on.

With an additional - at the beginning of the optstring it's possible to catch such issues and piggy-back on the default switch to print a message that suggests using the help.

[graeme-a-stewart]

Good that you caught this @amete! That's quite non-obvious behaviour IMO.