Some CLI apps with subcommands accept top level options anywhere in the arguments, some - like 'ip' - expect <command> <command options> <subcommand name>

Some CLI apps with subcommands accept top level options anywhere in the arguments, some - like 'ip' - expect <command> <command options> <subcommand name> <subcommand options> <arguments> The advantage of that approach is that you don't have to worry about naming collisions between the command and subcommand option sets, which can be really handy - especially in applications with pluggable and/or user supplied subcommands, so you can add top level options without worrying about breaking somebody else's extensions. The disadvantage is, well, what just happened to you. (note that I personally really like the pedantic approach because it fits my brain, but I'm -not- trying to endorse it as better in general since it's very definitely a trade-off and one that often isn't a good one overall)