Confusing error message when options for `python` are erroneously quoted

Bug report

Bug description:

#!/bin/python -q -i

I was writing an unrelated post about shebang lines tricks+tips, and happened to pick python as an example, only to discover some weird behavior. The above gets parsed as /bin/python "-q -i" <path/to/script>

But the message python prints is quite confusing:

Unknown option: - 
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

What's happening is that the "unknown option" is a single space, being parsed as a short-form option, and printed. But the output is pretty opaque, since the space is not quoted, and it's just a trailing invisible space.

Aside: Several other invalid one-byte options like \n get printed wrongly. This doesn't seem worth fixing.

Proposed fix:

I think the shebang case happens to users often enough that it would be good to have some kind of better error message if a short-form options list contains either of

• - (this would require scanning ahead!), which either indicates some quoting problem, or an incorrect long-form option (-check-hash-based-pycs rather than --check-hash-based-pycs).

I think a good error message could be unknown option: -q -i or unknown option: "-q -i". Quoting the argument when it contains a space seems clearer to me.

The current long-form options have pretty clear error messages either way, mostly by happenstance.

Currently, -help-* parses as -h which then prints help, stopping option parsing. I have no strong opinion about whether that behavior is better or worse than printing an error message.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

复现报告中的 shebang 调用 /bin/python -q -i，并检查 CPython 的命令行选项解析和错误报告入口点。重点关注带引号的选项字符串如何变成短格式选项，然后验证生成的诊断信息能够明确标识无效参数，同时不改变其他无关的无效单字节选项行为。