opened
andschwa
username_0
VSO create date - 12/22/2015 11:04:00
Implement a PowerShell cmdlet that returns the OS
issue
created
andschwa
username_0
I'm adding this to the Hacktoberfest issues. It's a feature request that really just needs a design first (so an implementer may want to start with an RFC), or propose a cmdlet/module that can just be imported (rather than built into SMA).
comment
created
joeyaiello
username_1
Changed the title to reflect that this issue addresses more detailed OS/environment info (a la `uname -a`) 

I would say that #1635 is not a dupe, but rather a slightly different ask to add the very basic OS info as a property to `$PSVersionTable`
comment
created
iSazonov
username_2
[Some comment about uname](http://unix.stackexchange.com/questions/136959/where-does-uname-get-its-information-from)
[uname sources](https://launchpad.net/ubuntu/+source/coreutils/8.25-2ubuntu2)

A brief summary: 
1. `uname` use syscall to get values from kernel.
2. some from the values is compile time kernel contants.
3. `uname` returns platform-dependent values (at compile time used `#if`)

Thus, the command may return unpredictable results depending on the platform and linux distrib.
I believe that we should have own `system info` object.

So questions:
what is the `OS information`?
what is the `environment information`?

Would it be a good start  to pay attention to `get-computerinfo` that returns tons of information about Windows and determine what properties we should port and properties we should add?
comment
created
joeyaiello
username_1
I also wonder what the delta is between this and bringing `System.Environment.OSVersion` into `$PSVersionTable` with #1635
comment
created
jeffbi
username_3
Currently, Get-ComputerInfo pulls three items from the Registry and uses five PInvoked native functions. Pretty much everything else comes from WMI.
comment
created
paulbailey1979
username_4
Is this still up for grabs? What about a cmdlet that returns properties similar to Ansible's setup module - https://github.com/ansible/ansible-modules-core/blob/devel/windows/setup.ps1 . This is the Windows source but a same named module exists for Linux that returns similar properties if possible. I'm not sure what's possible on Mac except it's like unix in some areas.
comment
created
iSazonov
username_2
@username_4 Feel free to grab this. Now we is on .Net Core 3.0 and we should review that it exposes useful for us.
comment
created
rjmholt
username_5
Just came across this issue.

I've done some work close to this in the PSScriptAnalyzer repo, [here](https://github.com/PowerShell/PSScriptAnalyzer/blob/development/PSCompatibilityCollector/Microsoft.PowerShell.CrossCompatibility/Collection/PlatformInformationCollector.cs), where we collect platform information.

A few points:

- CIM/WMI isn't available on all platforms (even some Windows ones, due to lockdown) and isn't terribly fast. In cases where a Windows SKU ID is wanted, there are one or two alternatives.
- The [`uname` syscall](http://man7.org/linux/man-pages/man2/uname.2.html) is very inconvenient to p/invoke since it requires setting inline arrays of platform-dependent size on a struct passed in ([StackOverflow question discussing this](https://stackoverflow.com/questions/55195344/get-uname-release-field-from-c-sharp-in-net-core-on-linux)). On Linux, it's much better to read from `/proc/sys/kernel`. macOS I haven't explored, but hopefully either (1) there's some other reasonable way to access that information, or (2) the size of `struct utsname` is more reliable
- `[System.Runtime.InteropServices.RuntimeInformation]::OSDescription` might be ok to use on macOS. It's a problem on Linux because it doesn't capture the kernel version fully (if you're on an alternative kernel or patchset, there's no info on that).
- The `/etc/*-release` files are also worth capturing on Linux and are readily parseable as CSV/INI. However, they're not well standardised.
    - [This man page](https://www.linux.org/docs/man5/os-release.html) summarises the `os-release` concept. It's surprisingly involved.
    - `lsb-release` is a less formalised standard, but is still widespread. [This gist](https://gist.github.com/natefoo/814c5bf936922dad97ff) captures variants on many distros
comment
created
SteveL-MSFT
username_6
@username_4 if you want to tackle this, I would suggest starting with a RFC detailing what info will be collected (and how) as I'm sure there will be some debate on what information is most critical to collect
comment
created
lukeb1961
username_7
coming up to its fifth birthday...
comment
created
adityapatwardhan
username_8
We recommend that this should be released to the gallery as a separate module.
comment
created
rkeithhill
username_9
FYI, this approach is handy on Linux:
```
$osRelease = Get-Content /etc/os-release | ConvertFrom-StringData
$osRelease

Name                           Value
----                           -----
NAME                           "Ubuntu"
VERSION                        "18.04.4 LTS (Bionic Beaver)"
ID                             ubuntu
ID_LIKE                        debian
PRETTY_NAME                    "Ubuntu 18.04.4 LTS"
VERSION_ID                     "18.04"
HOME_URL                       "https://www.ubuntu.com/"
SUPPORT_URL                    "https://help.ubuntu.com/"
BUG_REPORT_URL                 "https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL             "https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME               bionic
UBUNTU_CODENAME                bionic
```
comment
created
G31st
username_10
Any traction on this ?
comment
created
lukeb1961
username_7
I see other people have done interesting things in collating this sort of info.
https://github.com/Jinjinov/Hardware.Info
comment
created
doctordns
username_11
The CMDLETS Working Group has reviewed this issue and feels that this is a great candidate for a community module held on the PowerShell Gallery.
As such, we are closing this issue as **Will Not Implement**.
There are some published modules and scripts that already met this requirement.
We urge the original poster and others to collaborate on a community module if the existing scripts/modules are not satisfactory. 
If there is adequate interest in such a cmdlet, the working group can review this decision.
comment