In this case, the rpcport argument is silently ignored:
-testnet -nolisten -server -connect 192.168.1.11 -rpcport=12345
However, when adding a = after connect, it works, i.e.
-testnet -nolisten -server -connect=192.168.1.11 -rpcport=12345
It could be that the first is simply wrong; in that case, it should probably show an error message.
I didn't look in the code, but if a case does not match the detection routine, why should there be an error? If the function searches for -connect= to do sth. it's not said it should throw an error if it only gets -connect.
Because it frustrates the shit out of users if they pass arguments and they somehow, without any clue, don't work.
Edit: and yes, it is a low-priority issue, but I do want to put it here just in case.
I understand the intention, so you propose a standard for all parameters / switches an not only certain ones, right?
supplied "-connect IP" -> parameter incomplete
supplied "-conne=" -> parameter not recognized
Yep, something like that. I don't think the verification has to go very deep, just some sanity check.
my biggest gripe with the above really was that the rpcport argument is ignored, because the connect part is wrong, without any indication of either.
See the extensive discussion in #4194 on possible solutions for this.
Other long-term improvements to option parsing would be:
Also unknown (=deprecated) params should be detected.
Links to #4194 (comment)
It would be also nice if all the glohal initializations were in init.o (obviously not for bitcoin-tx) and getArg () [which internally uses the global argsMap] wasn't call from all over the place (and new places when we introduce new functionality but are too lazy to properly implement the new command line options or is not a priority to o things right(tm) (ie like in the case of the mempool limit ).