If headless conversion failed or aborted, as seen with examples from bug 97392 or bug 148253, it still returns error status 0. It should return some specific error. To reproduce, run a script with: /instdir/program/soffice --headless --convert-to xlsx password-to-open.ods echo "status is $?"
I agree that we need to introduce a "*some* commands failed" return code. Note that a command line is not necessarily a simple "soffice file", but it may have multiple files, and multiple commands (allowing one to print several files, and convert several files at the same command line). So it is possible that only *some* of them failed. Additionally, failures are different: some may be absent; some may be corrupt, or couldn't be exported using unavailable export filters ... so it is not a simple task. The "some error processing some file" is very different from other kinds of failures (that set the error codes) - like crashes, restart requests, etc. Interesting, what is a convention commonly used in such a case?
Automated bibisect cannot be done now for those cases. I think that there should be multiple status errors for different cases. Why not start for a simple and most common case of single conversion that fails or is aborted or source file not found. These are reserved Bash exit codes https://tldp.org/LDP/abs/html/exitcodes.html.
Stephan, do you know if that's feasible? IIRC, we can return rather arbitrary stuff coming from some external APIs, so can we declare some private error codes range, and make it public API?
(In reply to Mike Kaganski from comment #3) > Stephan, do you know if that's feasible? IIRC, we can return rather > arbitrary stuff coming from some external APIs, so can we declare some > private error codes range, and make it public API? I don't understand the above. Why not keep things simple and if any --convert-to operation fails call std::exit with EXIT_FAILURE rather than EXIT_SUCCESS.
(In reply to Stephan Bergmann from comment #4) > Why not keep things simple and if any --convert-to operation fails call > std::exit with EXIT_FAILURE rather than EXIT_SUCCESS. If that's an option - then great! Do you mean "std::exit after the first failure"? How a user would know if some previous ones succeeded? I suppose that EXIT_FAILURE is more about inability to run. But having another dedicated value for the case would likely make it simple enough, and still distinguishable?
(In reply to Mike Kaganski from comment #5) > I suppose that EXIT_FAILURE is more about inability to run. ... as *we* use it, not implying it's what stdlib means :-)
(In reply to Mike Kaganski from comment #5) > Do you mean "std::exit after the first failure"? What I had thought about was to change the code so that where apparently it currently unconditionally does the equivalent of std::exit(EXIT_SUCCESS), make it do the equivalent of std::exit(EXIT_FAILURE) if any of those --convert-to operations had failed (after processing all of them). But stopping after the first failing one might be fine as well. > How a user would know if some previous ones succeeded? Why would we care? If the user wants to have more precise information about which operations succeeded or failed, they could either call soffice for each of them individually, or they could presumably use the UNO API to do the same operations with more fine grained error reporting. > I suppose that EXIT_FAILURE is more about inability to run. But having > another dedicated value for the case would likely make it simple enough, and > still distinguishable? EXIT_FAILURE is all that the C/C++ standards portably offer. It traditionally translates to an exit status of 1 on Posix (and Windows), which traditionally represents a catch-all "failure" status in those environments. I still fail to see a need for a more specific exit status for "some --convert-to operation failed" in those environments.
I think it's safe to put New. Anything is better than current 0 so a single error would be good and this bug could be closed. As for why more would be better, I listed some cases: conversion fails or is aborted or source file not found or source password protected.
I noticed another aspect of this. soffice-convert && app-to-open doesn't work, at least in Windows, because soffice immediately gives 0 for %errorlevel% so app-to-open opens immediately after soffice-convert is run, when no converted file exists.
(In reply to Timur from comment #9) What is "soffice-convert"? Is the proper console mode `soffice.com` used, that is intended to work properly in command line and batch mode [1], and allows use of the program name without extension from command line? [1] https://mikekaganski.wordpress.com/2018/11/21/proper-console-mode-for-libreoffice-on-windows/
(In reply to Mike Kaganski from comment #10) > (In reply to Timur from comment #9) > What is "soffice-convert" That was meant to be: soffice.exe --headless --convert-to ext > Is the proper console mode `soffice.com` used, > that is intended to work properly in command line and batch mode [1], and > allows use of the program name without extension from command line? No, I just learned about it. And really it's working properly, it waits for a command to finish to continue with the next one. Thanks.