How to obtain LibreOffice version on Windows using a (perl) script, i.e. output to console?

English
,
#1

My application uses LO to convert files in batch mode, i.e. using command-line arguments such as --convert-to, but requires a minimum LO version (7.2).

On *nix I can run soffice --version and examine the result on stdout/err. However on Windows it pops up a separate console with the version string, and so my application can not intercept the result.

How can I tell LO to output batch-mode messages to the console? Or some other simple way (i.e. not by implementing a UNO client!) for a Perl script to determine what version soffice is?

I read previous discussion about how there is no reliable way for a GUI app to communicate with a console script. However I also read that any windows app can write to stdout or stderr if it want so. Can someone who actually understands this comment?

From a user perspective, I think LO should output messages to the console if --headless or --invisible args are used…

#2

Blame Windows. If things didn’t change, for GUI apps, stdio (stdin/stdout/stderr) are not connected to a terminal console. If there still (I didn’t touch Windows since almost a decade) is a soffice.com executable binary helper, that is used to glue things; maybe invoking that explicitly instead of soffice.exe might help.

1 Like
#3

It does, but it solves only one of two obstacles. You have to change to old cmd.exe first, then call soffice.com --version to get the message in the same window/shell where you typed the command.
.
But this should be no big problem for a perl-script…
.
Testing shows: If you redirect the output of the PowerShell-Call like

& soffice.com --version >LOVersion.txt there is no difference to cmd.exe

So follow the advice by @erAck and call soffice.com
(Tested with Win10 Pro 22H2 and LibreOffice 7.2.6.2 x86 )
.

May not always be possible. I can append parameters like --headless also to calls from Icons in Windows. And if LibreOffice is not started from a command-line there maybe is no console to write to…

#4

I don’t understand, why is a console needed?

Do you mean that a Perl script which itself was not started from a command-line can not run a sub-command and capture it’s stdout through a pipe?

(The --headless option would never be used by GUI users, only by someone/something which knew what to expect – no?)

#5

Can someone point me to a description of what “soffice.com” is, or where it is documented? Does it accept all the same command-line arguments as soffice.exe ? What’s the difference?

#6

soffice.com is a wrapper binary that attaches stdio and executes soffice.bin (I think, or was it .exe? I don’t remember), it should forward all command line arguments. Just try.
It’s mentioned in the help for Windows, note the slight difference to help for other systems.

That was in context of executing from the command line and getting any stdio. Remember you were the first to mention console in your original question: “From a user perspective, I think LO should output messages to the console”.

If you start a program via execv…() calls then of course you don’t need a console. But you also don’t get any stdio if you execute a GUI .exe because Windows just doesn’t let it have stdio. Hence execute soffice.com

2 Likes
Makro systemweit bleibend speichern
#7

That is to long ago. IMHO we used .com with MS-DOS before they moved to .exe
In the years also exe-files were changed internally more than once. MSDN should have docs on com/sys/exe/dll.
.
But for your case: The file soffice.com is in the same folder as the exe, so you have to call it with extension, as otherwise .exe is the default.
.
And if documentation only refers to soffice, I’d assume to be able to use the same command-line options for .exe and .com until meeting problems.

#8

No - as I wrote: You can mix environments. I can modify the starting of the “gui type” sessions with the same parameter “headless”, so it will just not open the window (hidden is also an option). But at this time it is to late to inherit a console/command-line environment for communication.
.
I could also run LibreOffice to communicate via a port, but you did exclude UNO-solutions in your question…

#9

Thank you. That is exactly what I need.

#10

See what you did here?
The “thank you” comment is a nice and polite response.
Marking that comment of yours as the solution means that you give yourself credit for having solved your issue. You surely meant to place credit where credit is due (@erAck), right?
To “formally” do that, you mark his comment (which you quoted) as the solution.

This is not intended for “shaming”. No offense intended at all. The inherent distinctions are not obvious, so it is easy to make a mistake. I have still posted this comment in the open instead of as a personal message because I thought it to be a matter of public interest.

Giving others credit boosts their “trust score” here. In turn, this provides trusted users with additional abilities, which hopefully makes the site run more smoothly.

#11

Note that the com extension has nothing to do with that old MS-DOS executable file format. It is used to disambiguate two wrapper executables, both actually running the main soffice.bin, but using two different Windows subsystems. The com executable is a normal PE binary.

1 Like

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.