When calling "unoconv --listener --format=pdf file.odt" it'd be nice to start the listener (in case it does not exist, yet) and convert the file.
This might be related to issue #29 .
Euhm, I am getting confused. If you run unoconv --listener, the aim is to run one instance of soffice.bin to do all subsequent conversions for you.
If you don't run unoconv --listener, it will start an soffice.bin listener on every invocation, and then tears it down after use. So doing unoconv --listener --format=pdf file.odt makes not sense to me. Just do unoconv --format=pdf file.odt instead, or even unoconv file.odt as PDF is the default output format.
unoconv --listener --format=pdf file.odt
unoconv --format=pdf file.odt
Maybe the man page should reflect this better, and we should not allow any other options with --listener ?
In my usecase I cannot make sure the listener is already running when launching unoconv. In case it does not run already, I'd like to launch it automatically. The file should be converted and the listener should stay open for further calls.
Please, tell me in case I'm wrong with this?!
Ok, I understand. So you really want to push it to the background.
The main reason why we did not do that in the past, is because once it runs in the background, you don't have any means of killing it afterwards. And the problem with LibreOffice is that in certain cases it becoms unstable and unusable, even when the listener is still accepting connections. The result is that all subsequent conversions fail.
Of course, what you could do is kill any remaining instances using pkill and start the conversion again. So maybe your use-case has some value. It was never intended to be used like that, but one might do it nevertheless. Can I suggest to make this optional, so that this change does not impact existing users ?
I would go for -D / --daemon, what do you think ?
-D / --daemon
Hmm... We could return the pid of the listener process...
-d / --daemon sounds good to me :-) . Is it possible to somehow recognize whether LibreOffice hangs or not to kill and relaunch it automatically?
Detection that it hangs is difficult, but what would be possible is to give it a certain amount of time and beyond that kill the process, and start over. But it was a deliberate decision not to go and work around these problems. It is in our advantage to fix the outstanding issues in LibreOffice by reporting them upstream.
So what I prefer is to make unoconv report errors better instead.
I would not return the pid of the process. If people need control over the process, they should not use -D / --daemon. Then they can use shell job control or programming language process management functionality. It's mostly the shell functionality and compatibility that I was concerned about.
Fixed by contribution, thanks !