Bug 51639 - 'SOFFICE.EXE --VERSION' starts LibO Start Center instead showing version
Summary: 'SOFFICE.EXE --VERSION' starts LibO Start Center instead showing version
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Andras Timar
URL:
Whiteboard: target:4.2.0 target:4.1.4
Keywords:
: 51846 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-07-01 18:21 UTC by Olivier Hallot
Modified: 2013-10-21 13:35 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot Version dialog (5.44 KB, image/png)
2013-10-21 07:35 UTC, pierre-yves samyn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Hallot 2012-07-01 18:21:17 UTC
In MS Windows command prompt invoking "soffice.exe --version" does not work.

At least I think it should print on stdout the version number and quit. But nothing is printed and the application launch.

Same issue in 3.5 branch.
Comment 1 Florian Reisinger 2012-07-06 08:23:58 UTC
Hi!
Can't confirm that...
Please look for the earliest version...
Comment 2 pierre-yves samyn 2012-07-07 22:55:40 UTC
Hello 

I confirm "soffice.exe --version" or "soffice --version" doesn't work.
(launching the application if it is not already open)

Verified with with :

XP : LibO 3.4, 3.5
Windows 7 64bits : LibO 3.5.4, Version 3.6.0.0.beta3 (Build ID: 3e2b862)

Regards
Pierre-Yves
Comment 3 Rainer Bielefeld Retired 2012-07-07 23:52:16 UTC
*** Bug 51846 has been marked as a duplicate of this bug. ***
Comment 4 Rainer Bielefeld Retired 2012-07-08 00:27:41 UTC
[Reproducible] with Server Installation of  "LibreOffice 3.6.0.0.beta3  German UI/Locale [Build-ID: 3e2b862] on German WIN7 Home Premium (64bit) 

I changed to program folder in command line modus, "soffice.exe --version" simply started LibO 3.6.0.0.beta2, no version info!

This command parameter handling might be completely missed up:
In 3.3 all commands were with a single "-" in front
In Help for 3.4.5 with 'soffice.exe -h' I see that 'soffice.exe --h' should show Help, but only 'soffice.exe -h' will work, parameter "--h" simply starts LibO without any help. Same with LibO 3.5.3

"--version" Already did not work with 3.5.3RC1

@Florian:
Please contribute precise information with what version you tested and what your result was.

@Tor:
How can we get a cleanup of Help and available functions?
Comment 5 Florian Reisinger 2012-07-08 00:37:14 UTC
Sorry, working through too many bugs. It was Linux... and 3.5.3.2 + 3.6b3

Result: Something like: LibreOffice 3.5 and LibOdev 3.6. Definitely only Windows bug...
Comment 6 Rainer Bielefeld Retired 2012-07-08 01:19:53 UTC
@Florian:
Thx
Comment 7 Don't use this account, use tml@iki.fi 2012-07-08 05:34:22 UTC
And exactly what kind of users would even try to run such a command "soffice.exe --version" from the command prompt? Only users who are perfectly capable of finding out what version of LO (or OOo, or AOO, all of which, AFAIK, also have a soffice.exe) they are running in another way. Like looking at Help:About. Or am I missing something?
Comment 8 pierre-yves samyn 2012-07-08 05:43:09 UTC
(In reply to comment #7)
> And exactly what kind of users would even try to run such a command...

This is exactly the question I asked myself :)

This option did not exist in OOo 3.2.1 and I wonder why it was added to LibreOffice help...
Comment 9 Olivier Hallot 2012-07-08 05:50:45 UTC
soffice --version  is useful if invoked in a script, so that you can determine the version and take action depending on the results.

e.g. if version < 3.5.4 then upgrade

On these days of time-based releases, you can easily get a mixed version deployment in a enterprise.
Comment 10 Don't use this account, use tml@iki.fi 2012-07-08 06:06:24 UTC
But we don't add the "program" folder to the system PATH, do we? So to find out from where to run soffice.exe the script would need to look in the registry or something, no? Is it then really much harder for the script to just look in the version.ini file in the same location as soffice.exe. Not that I am sure if version.ini contains anything usable, at least in my LO which in Help:About identifies itself as 3.5.3.2 nothing in version.ini says 3.5.3.2...

Anyway, one basic problem right in the initial question is the concept "print on stdout". soffice.exe is a so-called "GUI executable" which means that its stdout and stderr are *not* connected anywhere, especially not to the console window even if they are started from a cmd.exe in a console window. One would have to redirect stdout from the cmd.exe command line to a file, or pipe it to for instance the "more" command.

My recommendation is that instead of making soffice.exe --version print some kind of version information to "stdout", we should just make sure version.ini contains some version information that matches the version number as shown by Help:About (in addition to the other cruft it currently contains, some of which is probably fairly pointless).
Comment 11 João Mac-Cormick 2012-07-08 11:34:24 UTC
So the solution would be to evaluate the file "%LIBO%\program\version.ini"

[Version]
ProductMajor = 350
ProductMinor = 1

It could be added

XXXX = 3.5.0

To avoid confusion on the type and version 3.11.1 version 3.1.11...

Is this the correct procedure?

=================

Então a solução seria avaliar o arquivo %libo%\program\version.ini

[Version]
ProductMajor=350
ProductMinor=1

Poderia se acrescentar

XXXX=3.5.0

Para evitar confusão do tipo versão 3.11.1 e versão 3.1.11...

Seria este o procedimento correto?
Comment 12 Don't use this account, use tml@iki.fi 2012-07-09 12:53:14 UTC
The BuildVersion, ProductBuildid. ProductMajor, ProductMinor, ProductSource, ReferenceOOoMajorMinor and maybe more values in version ini are probably mostly meaningless by now, and should be removed in 3.7, or at least 4.0. (The three-digit number "350" used to refer to how version control was structured at Sun/Oracle in OO.o times, "master workspaces" etc, and has little relevance today.) Adding a new value that corresponds to the user-visible version from Help:About definitely makes sense IMHO.
Comment 13 Rainer Bielefeld Retired 2012-07-09 14:04:07 UTC
> The BuildVersion, ProductBuildid. ProductMajor, ProductMinor, ProductSource,
> ReferenceOOoMajorMinor and maybe more values in version.ini are probably mostly
> meaningless by now, and should be removed in 3.7 ...

I think that's the way we should go, at least MsiProductVersion=3.6.0.0.beta3 and some info the verson.ini in current builds is already really useful, no idea whether the obsolete looking parts still are used somewhere or not. I believe we should drop that garbage in Master and we will see what happens.
Comment 14 João Mac-Cormick 2012-07-09 23:00:27 UTC
> "Adding a new value that corresponds to the user-visible version from Help:About definitely makes sense IMHO."

Perfect! It could be ProductVersion or SuiteVersion...

It would be interesting to keep the variables MsiProductVersion and ProductCode. They are useful...
Comment 15 Olivier Hallot 2012-09-19 14:57:40 UTC
Another borked option for soffice.exe : see bug 55098
Comment 16 Thomas Arnhold 2013-10-20 10:21:42 UTC
NOT exactly reproducible on Windows 7 with Version: 4.1.2.3
Build ID: 40b2d7fde7e8d2d7bc5a449dc65df4d08a7dd38

Open cmd. Goto C:\Program Files (x86)\LibreOffice 4\program\

Type "soffice --version" or "soffice --help" and and a message box with version information will appear.

Alternatively enter "C:\Program Files (x86)\LibreOffice 4\program\soffice --version" into the search box of the start menu and execute it.
Comment 17 pierre-yves samyn 2013-10-21 07:35:16 UTC
Created attachment 87910 [details]
Screenshot Version dialog
Comment 18 pierre-yves samyn 2013-10-21 07:37:06 UTC
Hello

(In reply to comment #16)
> NOT exactly reproducible on Windows 7 with Version: 4.1.2.3
> Build ID: 40b2d7fde7e8d2d7bc5a449dc65df4d08a7dd38

Yes, no more reproducible on Windows 7 64bits with
Version: 4.1.3.1
Build ID: b42498da0e3f91b17e51b55c8295ec4f8f22087

Note: The dialog box displays the version number but also the two expressions (see copy attached screen):
LEFTRIGHT
BOTTOM

Regards
Pierre-Yves
Comment 19 Andras Timar 2013-10-21 07:52:53 UTC
soffice.exe --version displays a dialog box with the version string (version number + git hash). With the fix below, it does not display LEFTRIGHT and BOTTOM strings. For different problems, please file new bugs.
Comment 20 Commit Notification 2013-10-21 07:59:20 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0980948795a77fcbb19a464a533e31d6529526a1

fdo#51639 soffice.exe --version displays a dialog box with the version number



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 21 Commit Notification 2013-10-21 13:35:45 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=29ef37395884c72898c77185e5e00898ad98f2c7&h=libreoffice-4-1

fdo#51639 soffice.exe --version displays a dialog box with the version number


It will be available in LibreOffice 4.1.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.