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 のコマンドラインオプション解析とエラー報告のエントリポイントを調査します。引用符で囲まれたオプション文字列が短形式のオプションになる仕組みに焦点を当て、その結果の診断メッセージが無効な引数を明確に識別することを、無関係な無効な 1 バイトオプションの動作を変更せずに検証します。