Bug 140286 - CALC formula =INFO("OSVERSION") gives wrong output
Summary: CALC formula =INFO("OSVERSION") gives wrong output
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0
Keywords:
Depends on:
Blocks: Cell-Formula
  Show dependency treegraph
 
Reported: 2021-02-09 09:08 UTC by pharmankur
Modified: 2024-11-09 13:45 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
INFO("OSVERSION") formula result example (22.28 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-02-09 09:10 UTC, pharmankur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pharmankur 2021-02-09 09:08:38 UTC
Description:
I am using Linux mint 19.3 64 bits with libreoffice 7.1.0

CALC formula =INFO("system") gives output as " LINUX " ... This is correct

But, I have noticed that CALC formula =INFO("OSVERSION") gives output as " Windows (32-bit) NT 5.01 " ... This is WRONG.

Steps to Reproduce:
1. From Linux 64 bit machine Open LO Calc 
2. In a cell type formula =INFO("OSVERSION")


Actual Results:
It will show " Windows (32-bit) NT 5.01 "

Expected Results:
It should be Linux (64-bit) ..etc whatever ... but not WINDOWS !


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Enclosed spreadsheet file showing up this error Vs my actual system information
Comment 1 pharmankur 2021-02-09 09:10:07 UTC
Created attachment 169604 [details]
INFO("OSVERSION") formula result example
Comment 2 Xisco Faulí 2021-02-09 10:04:02 UTC
Reproduced in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: dc1b416c684c4e2525978e48252d55d78adcfca8
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 3 Xisco Faulí 2021-02-09 10:04:38 UTC
@Eike, I thought you might be interested in this issue
Comment 5 Eike Rathke 2021-02-09 15:36:21 UTC
Reason probably being that it's there because of Excel Windows interoperability.
I'm unbiased, I don't mind if we change it to return the actual OS (and possibly version), but I also don't know the use case of this function/argument at all or if and how documents rely on it (and why).

Btw, what does current Excel on a current Windows return?
Comment 6 himajin100000 2021-02-09 15:46:00 UTC
Excel 2016 On Windows 10 Shows:

Windows (32-bit) NT 10.00
Comment 7 himajin100000 2021-02-09 15:46:50 UTC
64 bit MS Office may give different value (but I don't have 64 bit MS Office)
Comment 8 Regina Henschel 2021-02-09 15:48:37 UTC
(In reply to Eike Rathke from comment #5)
> Btw, what does current Excel on a current Windows return?

My Windows 10 Home, OS build 19041.746
is correctly reported by Excel as
Windows (64-bit) NT 10.00
and wrongly by LibreOffice as
Windows (32-bit) NT 5.01
Comment 9 Eike Rathke 2021-02-09 16:40:41 UTC
I presume we could use the same information as for Environment OS in the Help -> About dialog, which calls Application::GetHWOSConfInfo(). That can't be used though because it concatenates CPUs and OS, but a similar function could be introduced returning only the OS and version without label, i.e. using the overridden SalInstance::getOSVersion() return value. Whatever that gives for Windows might have to be massaged into shape to somewhat resemble the Excel string.

And what does Excel on MacOS produce?

I'd make this an EasyHack once we clarified what we actually want here..
Comment 10 pharmankur 2021-11-24 16:41:43 UTC
Any updates on this ?
Comment 11 Roland Kurmann 2021-12-19 16:17:22 UTC
"Windows (32-bit) NT 5.01" is a hard coded string in the source (interpr5.cxx).

It came with commit 2ff54fbac26a884e53e74f44db7831cc179a6a97 (2006).
Comment 12 Commit Notification 2022-01-01 15:52:49 UTC
scito committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4d0d4fb11f7251e0437ec8e6fe7b7693f3a31800

tdf#140286 fix INFO("OSVERSION") for Linux: return kernel version

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Eike Rathke 2022-01-01 15:56:30 UTC
If some devs on Mac and/or Windows could check with that patch added what Application::GetOSVersion() gives and whether the result is usable for the INFO("osversion") call?
See sc/source/core/tool/interpr5.cxx ScInterpreter::ScInfo()
Comment 14 Jan-Marek Glogowski 2022-01-01 16:18:18 UTC
I'm not sure how much sense it makes to show the Linux kernel version. Maybe just as a fallback, if "lsb_release -d" has no result? Not sure how common the lsb tools are installed. I doubt LO depends at all somehow on the Linux kernel version.
Comment 15 Chris Sherlock 2022-01-02 06:20:37 UTC
What should it show for MacOS?
Comment 16 Chris Sherlock 2022-01-04 01:11:14 UTC
On a Mac, I get "Macintosh (Intel) Version 11.6.2 (Build 20G314)"
Comment 17 Hossein 2022-01-04 09:14:42 UTC
(In reply to Jan-Marek Glogowski from comment #14)
> I'm not sure how much sense it makes to show the Linux kernel version. Maybe
> just as a fallback, if "lsb_release -d" has no result? Not sure how common
> the lsb tools are installed. I doubt LO depends at all somehow on the Linux
> kernel version.

I agree that knowing the Linux distribution and the version is much more important compared to the kernel version. Looking at the output of `cat /etc/*release` is usually fine, because it is OK in most Linux distributions.
Comment 18 Chris Sherlock 2022-01-04 12:01:52 UTC
Can someone test Excel on Windows with this function and tell us what they get back?
Comment 19 Chris Sherlock 2022-01-04 12:03:34 UTC
Hossein, most Linux systems are using systemd, so it is best to look at /etc/os-release; then fall back to lsb_release; if that doesn't work (there will be distros out there that don't support this - yes they are oddball) then we can fall back to just the kernel version.
Comment 20 Chris Sherlock 2022-01-04 12:43:05 UTC
Regina, sorry missed your comment. Do we want to implement precisely what Microsoft provides, or do we want the more detailed version information we provide in Application::GetOSVersion() for Windows?
Comment 21 Chris Sherlock 2022-01-13 15:34:08 UTC
The outcome at ESC just now is: noone uses Excel on Linux, probably not important.
Comment 22 BogdanB 2023-05-06 16:19:47 UTC
The same in
Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 23 Charles Williams 2024-10-12 10:49:51 UTC
On a M1 iMac (aarch64 hardware) running macos 15.0.1 (Sequoia) I get:

    Windows (32-bit) NT 5.01

using

Version: 24.8.2.1 (AARCH64) / LibreOffice Community
Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13
CPU threads: 8; OS: macOS 15.0.1; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded
Comment 24 Chris Sherlock 2024-11-09 13:45:28 UTC
That’s clearly buggy. I’ll need to look at my Macbook when I get it to see what it returns.