Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running ocrd or a processor without arguments should output --help AND return 1 #1209

Open
kba opened this issue Apr 15, 2024 · 4 comments
Open

Comments

@kba
Copy link
Member

kba commented Apr 15, 2024

          It looks like I should run `ocrd-froc-recognize --help` to get a result code of 0 if there is no crash instead of running `ocrd-froc-recognize` without any argument which always returns 1, even with Python 3.7 and Python 3.8 where it does not crash.

Most OCR-D processors return 1 when they are called without any argument, but ocrd from core is an exception which returns 0. Should that be changed?

Originally posted by @stweil in OCR-D/ocrd_froc#13 (comment)

@bertsky
Copy link
Collaborator

bertsky commented Apr 16, 2024

Most OCR-D processors return 1 when they are called without any argument, but ocrd from core is an exception which returns 0. Should that be changed?

I don't think so. Both behaviours are well documented. Processors adhere to the OCR-D CLI specification, and ocrd (being a multi-task CLI and not part of the spec) just yields the --help output, which is the most useful default.

@stweil
Copy link
Contributor

stweil commented Apr 16, 2024

@bertsky, thank you for pointing to the OCR-D CLI specification. Where is it documented that running ocrd without an argument should return 0? If there is no such documentation, it should be changed to return 1 for consistency with OCR-D processors and common command line tools like cp and others.

@bertsky
Copy link
Collaborator

bertsky commented Apr 16, 2024

Where is it documented that running ocrd without an argument should return 0?

That's click's default (because traditionally that's how multi-task CLI behave).

If there is no such documentation, it should be changed to return 1 for consistency with OCR-D processors

I totally disagree.

First of all, this would break existing usage without even a reason.

Second, there is simply no need for "consistency" with OCR-D processors, as this is a different kind of CLI, as I have already pointed out.

@stweil
Copy link
Contributor

stweil commented Apr 16, 2024

That's click's default (because traditionally that's how multi-task CLI behave).

Please give more evidence for that statement. I just tried git. Is that a multi-task CLI? How does it behave?

First of all, this would break existing usage without even a reason.

Do you have a real-life example of this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants