in case of "-flush-logs", with a single instead of a double dash, all letters following the dash are interpreted as "short" single letter options, and "f" is the short option for

  -f, --force         Continue even if we get an SQL error.

So the "--force" behavior should maybe be changed to only take effect after option parsing has been completed, not right away as soon as the option is seen?

hholzgra,
Sorry, I don't quite understand – how would postponing the effect of force affect this particular case? Since there is no SQL error, no matter when --force starts working... I must be missing something, could you please expand on it?

@ ivan.stoykov@skysql.com :
Ivan,
Indeed, -flush-logs is interpreted as -f -l -ush-logs, that's normal, nothing new here.
I don't suppose you have a user sh-logs in your setup, but apparently you have an anonymous one, so I don't see any problem here. What would you consider to be the expected result?

I still think this is not proper handling of that argument
using

-flush-logs

should be interpreted in the same way as

-ignore-table

- as a non valid mysqldump argument

But it is interpreted exactly the same way as -ignore-table.
-ignore-table is interpreted as -i -g -n ..., and fails because there is no such option -g (which it says in the error message as you quoted in the description).

How exactly do you suggest to handle it properly? Prohibit the widely used syntax ps -aux etc., and only allow single-letter options? I doubt the users will appreciate it... Parse the options to search for common words and forbid the command line if we found any? It's kind of weird and not reliable anyway.

like:
one additional check for the complete string after the single dash , if there is a match within the array of the valid 'double dash' arguments throw an error

Matching the command line to complete option names does not solve the general problem; In order to achieve anything at all with this, we would also have to prohibit prefixes, like ''ord'' for 'order-by-primary' and such, and I doubt users will be happy about that. It's one thing to disapprove using contractions in server options – as server starts rarely, usually with a config file and minimal command line, – and quite another to make users write complete, sometimes very long options for frequently used command-line client tools.

All in all, I vote against it, but it's not my decision to make, I am converting it to an FR and passing over to serg for further consideration (or maybe he can invent a better solution).
Also, maybe hholzgra in his first comment had some alternative solution in mind, and I just couldn't understand it.

This is not a bug, but expected and documented behavior. See elenst explanation above.