Replies: 4 comments 1 reply
|
Having this code at the beginning of our app seems to do the trick but seems hackish. |
|
Non-zero exit codes aren't bugs. Returning 2 here is absolutely fine, it merely indicates that the code exited in some other way than running a command successfully. |
|
Thanks @davidism. Treating non zero as error is a common convention in automation of commands and we follow that convention with our app. Is there a clean way to make it zero? The best we found so far is to reset the exit code in our existing top level context setting. Is it reasonable? |
|
Showing help is what happens when you don't type a command, pass invalid args, etc. I don't understand what you're trying to automate here, this is showing help to human users so they understand that they need to pass arguments when they didn't. If you were automating something, you'd pass the correct args, and as you say you'd expect a non-zero exit if you don't write your automation correctly. |
|
We represent to users that 'apio' is a shortcut for 'apio -h' and 'apio devices' is a shortcut for 'apio devices -h', a convenient way to explore the tree, so returning error code 2 for 'apio' and OK for 'apio -h' doesn't fit our model. |
Uh oh!
There was an error while loading. Please reload this page.
We have an app called
apioand when we type justapiowe used to get the help text which is nice and intuitive (we do the same throughout our cli tree) . Trying to migrate to the latest Click, we now get an error code 2 which is seems to be related to this commit #1489Is there a way to change the behavior to return 0 instead of 2? We consider the no-args-help to be a convenient feature and not a bug.
The app exit it at this point and I am not sure how to force the exit code back to 0.
click/src/click/core.py
Line 1381 in 91ac027
All reactions