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

feature request: exit status codes #229

Open
brnco opened this issue Jun 4, 2022 · 3 comments
Open

feature request: exit status codes #229

brnco opened this issue Jun 4, 2022 · 3 comments
Assignees

Comments

@brnco
Copy link

brnco commented Jun 4, 2022

I'd like to be able to evaluate the execution of the MediaConch CLI through the use of exit status codes. Using return codes would simplify Bash implementations of the MediaConch CLI by allowing the execution of MediaConch to be part of a conditional statement directly, e.g. if mediaconch -p policy.xml file.mkv; then...

Currently, MediaConch returns the same code, 0, for pass, fail, and error. To evaluate the pass/ fail/ error status of the execution, we have to parse the output text.

I think the following exit codes would suit my needs just fine:
0 = file passes validation
1 = file fails validation
2 = error in execution of MediaConch

You all are the best, thank you!

@JeromeMartinez
Copy link
Member

Currently, MediaConch returns the same code, 0, for pass, fail, and error.

No more since MediaArea/MediaConch_SourceCode#717 but globally true.
At the beginning we were thinking to use status code only for feedback of error in execution of MediaConch, but having an error code also for failures makes also sense.

@jens-st
Copy link

jens-st commented Oct 23, 2023

I ran into this issue as well on automated archiving processes with file validation tasks.
I'd like to request this feature too.
Maybe not by default but would it be possible to add a pure optional argument for the CLI version that can reflect the validation status of the checked file in any way in the return code?

@JeromeMartinez
Copy link
Member

@jens-st something doable, and right it may be better that it is an option in order to avoid incompatibility with previous version, or an option for previous behavior.

Still on our free support todo-list, no ETA.

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

4 participants