search

OCR-D / core

Collection of OCR-related python tools and wrappers from @OCR-D
https://ocr-d.de/core/
Apache License 2.0
118 stars 31 forks source link

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

Open kba opened 5 months ago

kba commented 5 months ago 
          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 https://github.com/OCR-D/ocrd_froc/issues/13#issuecomment-2053953307_

bertsky commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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?