8000 Implement a PowerShell cmdlet that returns detailed OS/environment information · Issue #419 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]
Skip to content

Implement a PowerShell cmdlet that returns detailed OS/environment information #419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
andyleejordan opened this issue Jan 22, 2016 · 30 comments
Closed

Implement a PowerShell cmdlet that returns detailed OS/environment information #419

andyleejordan opened this issue Jan 22, 2016 · 30 comments
Labels
Hacktoberfest Potential candidate to participate in Hacktoberfest Issue-Enhancement the issue is more of a feature request than a bug Resolution-External The issue is caused by external component(s). WG-Cmdlets general cmdlet issues WG-DevEx-Portability authoring cross-platform or cross-architecture modules, cmdlets, and scripts
Milestone
Future

Comments

@andyleejordan
Copy link
Member

VSO create date - 12/22/2015 11:04:00
@andyleejordan
Copy link
Member Author

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

@andyleejordan andyleejordan added this to the Preview 1+ milestone Jan 28, 2016
@JamesWTruher
Copy link
Collaborator

sure - I'll be happy to help with that

@palladia
Copy link
Contributor
palladia commented Feb 4, 2016

Need more requirements on this cmdlet...

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

???

@palladia palladia added help wanted and removed ready labels Feb 4, 2016
@andyleejordan
Copy link
Member Author

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

@JamesWTruher
Copy link
Collaborator

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

j

From: Andy Schwartzmeyer [mailto:notifications@github.com]
Sent: Thursday, February 4, 2016 1:12 PM
To: PowerShell/PowerShell-Linux PowerShell-Linux@noreply.github.com
Cc: Jim Truher Jim.Truher@microsoft.com
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//issues/419#issuecomment-180051628.

@zach-folwick
Copy link
Contributor

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

@andyleejordan andyleejordan mentioned this issue Feb 21, 2016
Closed
@andyleejordan
Copy link
Member Author

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
8000 Copy link
Collaborator

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 <notifications@github.commailto:notifications@github.com>
Sent: Sunday, February 21, 2016 11:52 AM
Subject: Re: [PowerShell] Implement a PowerShell cmdlet that returns the OS (#419)
To: PowerShell/PowerShell <powershell@noreply.github.commailto:powershell@noreply.github.com>
Cc: Jim Truher <jim.truher@microsoft.commailto:jim.truher@microsoft.com>

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.41/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.41/RELEASE_X86_64 x86_64

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

@andyleejordan
Copy link
Member Author

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
Copy link
Collaborator

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" <notifications@github.commailto:notifications@github.com> 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//issues/419#issuecomment-186906437.

@andyleejordan
Copy link
Member Author

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

@andyleejordan andyleejordan modified the milestones: Preview 2, Preview 1+ Apr 2, 2016
@joeyaiello
Copy link
Contributor

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
Copy link
Collaborator
iSazonov commented Nov 18, 2016 •
edited
Loading

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 SteveL-MSFT modified the milestones: post-6.0.0, 6.1.0 Mar 4, 2017
@SteveL-MSFT SteveL-MSFT removed the Hacktoberfest Potential candidate to participate in Hacktoberfest label Mar 4, 2017
@SteveL-MSFT
Copy link
Member

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
Copy link
Contributor

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

@jeffbi
Copy link
Contributor
jeffbi commented Mar 6, 2017

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

@SteveL-MSFT SteveL-MSFT removed this from the 6.2.0-Consider milestone Jun 21, 2018
@SteveL-MSFT SteveL-MSFT mentioned this issue Mar 1, 2019
Closed
@SteveL-MSFT SteveL-MSFT added this to the Future milestone Mar 1, 2019
@ghost
Copy link
ghost commented May 30, 2019

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
Copy link
Collaborator

@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
Copy link
Collaborator
rjmholt commented Jun 3, 2019 •
edited
Loading

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
Copy link
Member

@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

@lukeb1961
Copy link

coming up to its fifth birthday...

@adityapatwardhan adityapatwardhan added Issue-Enhancement the issue is more of a feature request than a bug and removed Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif labels Feb 25, 2021
@adityapatwardhan
Copy link
Member

We recommend that this should be released to the gallery as a separate module.

@rkeithhill
Copy link
Collaborator

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

@G31st
Copy link
G31st commented Jul 8, 2021

Any traction on this ?

@SteveL-MSFT SteveL-MSFT added Hacktoberfest Potential candidate to participate in Hacktoberfest and removed Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors labels Jul 8, 2021
@lukeb1961
Copy link
lukeb1961 commented Jul 14, 2021 •
edited by unfurl-links bot
Loading

I see other people have done interesting things in collating this sort of info.
https://github.com/Jinjinov/Hardware.Info

GitHub
Battery, BIOS, CPU - processor, storage drive, keyboard, RAM - memory, monitor, motherboard, mouse, NIC - network adapter, printer, sound card - audio card, graphics card - video card. Hardware.Inf...

@doctordns
Copy link
Collaborator
doctordns commented Feb 15, 2022 •
edited
Loading

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.

@iSazonov @SteveL-MSFT - can one of you please close this formally?

@iSazonov iSazonov added the Resolution-External The issue is caused by external component(s). label Feb 15, 2022
@ghost
Copy link
ghost commented Feb 16, 2022

This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.

@ghost ghost closed this as completed Feb 16, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Hacktoberfest Potential candidate to participate in Hacktoberfest Issue-Enhancement the issue is more of a feature request than a bug Resolution-External The issue is caused by external component(s). WG-Cmdlets general cmdlet issues WG-DevEx-Portability authoring cross-platform or cross-architecture modules, cmdlets, and scripts
Projects
None yet
Milestone
Future
Development

No branches or pull requests
0