exit
-
That just gave me the idea that it would be fun to inspect
exita little.Which led me down this path:
>>> repr(exit) 'Use exit() or Ctrl-Z plus Return to exit' >>> dir(exit) [(...), 'eof', 'name'] >>> exit.eof, exit.name ('Ctrl-Z plus Return', 'exit')Okay, cool, the "Use exit() etc." blurb appears because it's the function's
repr, and the string is assembled from itsnameandeofproperties.Now let's try to make our own:
>>> exit.__class__ <class '_sitebuiltins.Quitter'> >>> gtfo = exit.__class__() TypeError: Quitter.__init__() missing 2 required positional arguments: 'name' and 'eof'Oh Python, you shouldn't have.
>>> gtfo = exit.__class__("a big puff of smoke", "a sneaky skedaddle") >>> gtfo Use a big puff of smoke() or a sneaky skedaddle to exitBeauty!
Does gtfo() then work as expected?
-
They meant that you'd get the same message no matter what unrecognized option you use. So it's not like they added a specific check that if you type in -h they will give you the message, but instead you get the same message for any unrecognized option.
The thing in the OP only occurs if you type exit, so they specifically added that message to be shown when the interpreter clearly knows what you want, but you just didn't say it exactly right.
I mean, if I didn't use a correct flag, my next command will probably include -h / --help
-
I mean, if I didn't use a correct flag, my next command will probably include -h / --help
You aren't wrong, it wouldn't be bad for it to just print the help in that case, at least when running interactive.
For automation, printing the full help of a more complex command would completely trash logs.
-
Same energy as "Option
-hnot recognized; use--helpfor the list of options".Or more subtly, when the command uses BSD (nowadays Go) style single-dash args, so it wants
-helpand not--help.
