Powershell: Implement a PowerShell cmdlet that returns detailed OS/environment information

[andschwa]

VSO create date - 12/22/2015 11:04:00

[andschwa]

@JamesWTruher perhaps you could help us figure out how to do this properly. The C# code to determine Linux/Windows/OS X is trivial.

[JamesWTruher]

sure - I'll be happy to help with that

[palladia]

Need more requirements on this cmdlet...

$os = Get-OperatingSystem
$os | format-list *
Name : Linux
Version : 14.04.1-Ubuntu

???

[andschwa]

That we do. @JamesWTruher how do you think this cmdlet should work?

[JamesWTruher]

Since I doubt that wmi/cim is not available, it should probably reflect uname output (except as an object)

j

From: Andy Schwartzmeyer [mailto:[email protected]]
Sent: Thursday, February 4, 2016 1:12 PM
To: PowerShell/PowerShell-Linux [email protected]
Cc: Jim Truher Jim.[email protected]
Subject: Re: [PowerShell-Linux] Implement a PowerShell cmdlet that returns the OS (#419)

That we do. @JamesWTruherhttps://github.com/JamesWTruher how do you think this cmdlet should work?

—
Reply to this email directly or view it on GitHubhttps://github.com/PowerShell/PowerShell-Linux/issues/419#issuecomment-180051628.

[zach-folwick]

I could have swore we wrote a p/invoke that calls uname in C. It should be in monad-native

[andschwa]

FWIW, [System.Runtime.InteropServices.RuntimeInformation]::OSDescription on my MacBook returns a string very similar to uname -a.

> [System.Runtime.InteropServices.RuntimeInformation]::OSDescription       
Darwin 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64
> uname -a        
Darwin marvin 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64

[JamesWTruher]

Sigh, anything that returns a string is unfortunate. We should try to find out how that string is Created and use the data rather than the result

Sent from Outlook Mobilehttps://aka.ms/qtex0l

---

From: Andy Schwartzmeyer <[email protected][e-mail]>
Sent: Sunday, February 21, 2016 11:52 AM
Subject: Re: [PowerShell] Implement a PowerShell cmdlet that returns the OS (#419)
To: PowerShell/PowerShell <[email protected][e-mail]>
Cc: Jim Truher [email protected][e-mail]>

FWIW, [System.Runtime.InteropServices.RuntimeInformation]::OSDescription on my MacBook returns a string very similar to uname -a.

[System.Runtime.InteropServices.RuntimeInformation]::OSDescription Darwin 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64> uname -a Darwin marvin 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64

Reply to this email directly or view it on GitHubhttps://github.com/PowerShell/PowerShell/issues/419#issuecomment-186897474.

[andschwa]

Agreed. I wish their interface was better. I'm trying to play around with what's available so I can do a simple switch on the current OS. We should probably open an issue with .NET to get a better interface.

[JamesWTruher]

We should just look at the implementation, and see if we can use it

Sent from Outlook Mobilehttps://aka.ms/qtex0l

On Sun, Feb 21, 2016 at 12:21 PM -0800, "Andy Schwartzmeyer" <[email protected][e-mail]> wrote:

Agreed. I wish their interface was better. I'm trying to play around with what's available so I can do a simple switch on the current OS. We should probably open an issue with .NET to get a better interface.

Reply to this email directly or view it on GitHubhttps://github.com/PowerShell/PowerShell/issues/419#issuecomment-186906437.

[andschwa]

623 added basic support for this. Further implementation/refinement should be done in the Platform module.

[andschwa]

The platform module has been removed. The variables $IsWindows, $IsLinux, $IsOSX, and $IsCore are now an integral part of PowerShell.

[andschwa]

I think this issue should remain open as it covers the ability to have a "system info" object that tells you a lot more than which type of OS you're on.

[andschwa]

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).

[joeyaiello]

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

[iSazonov]

Some comment about uname
uname sources

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?

Update: Currently CoreFX parse a kernel's uname (see here and here)

[SteveL-MSFT]

Probably a big undertaking, but we should probably modify get-computerinfo to not rely on WMI and use .Net api's where possible to have it portable.

CC @jeffbi

[joeyaiello]

I also wonder what the delta is between this and bringing System.Environment.OSVersion into $PSVersionTable with #1635

[jeffbi]

Currently, Get-ComputerInfo pulls three items from the Registry and uses five PInvoked native functions. Pretty much everything else comes from WMI.

[paulbailey1979]

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.

[iSazonov]

@paulbailey1979 Feel free to grab this. Now we is on .Net Core 3.0 and we should review that it exposes useful for us.

[rjmholt]

Just came across this issue.

I've done some work close to this in the PSScriptAnalyzer repo, here, 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 is very inconvenient to p/invoke since it requires setting inline C-strings (i.e. char arrays) of platform-dependent size on a struct passed in (StackOverflow question discussing this). 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 summarises the os-release concept. It's surprisingly involved.
  
  
  • lsb-release is a less formalised standard, but is still widespread. This gist captures variants on many distros
  
  
• Getting the OS architecture may be harder than it looks because, last time I checked, some of System.Runtime.InteropServices.RuntimeInformation's APIs don't work properly on Win 7 kernels (https://github.com/dotnet/corefx/issues/33885).

[SteveL-MSFT]

@paulbailey1979 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