Tag Archives: Powershell

PSResourceGet Release Candidate is Now Available

This post was originally published on this site

Microsoft.PowerShell.PSResourceGet is a continuation of the PowerShellGet 3.0 project. The release candidate of this module under the new name is now available on the PowerShell Gallery. This release contains a number of bug fixes. This release is considered “go live” meaning that it is a fully supported release and expected to be of GA quality. After this release we don’t expect to make any changes before we make the module “Generally Available (GA)”. Please test out this module and report any issues so that we can resolve any blocking scenarios before this module becomes GA. Once this module becomes GA we will continue work with both bug patches and new feature releases.

How to install the module

To install from PSResourceGet (which is included in PowerShell 7.4 Preview 5)

Install-PSResource Microsoft.PowerShell.PSResourceGet -Prerelease

To install from PowerShellGet 2.2.5

Install-Module -Name Microsoft.PowerShell.PSResourceGet -AllowPrerelease

What is included in this preview

This release was focused on bug fixes, and did not introduce any new features

Bug Fixes

  • Bug fix for using Import-PSGetRepository in Windows PowerShell
  • Add error handling when searching for unlisted package versions
  • Bug fix for deduplicating dependencies found from Find-PSResource
  • Added support for non-PowerShell Gallery v2 repositories
  • Bug fix for setting ‘unknown’ repository APIVersion
  • Bug fix for saving a script with -IncludeXML parameter
  • Bug fix to write warning instead of error when package is already installed

For a full list of changes please refer to the changelog.

Documentation Updates

As a part of our efforts with this module we have also been updating the documentation for this module. Please check out the documentation and give us feedback in this repository so we can make improvements.

How to give feedback and Get Support

We cannot overstate how useful user feedback has been in the development of this module.

In order to give feedback or get support please open issues in our GitHub repository.

Sydney

PowerShell Team

The post PSResourceGet Release Candidate is Now Available appeared first on PowerShell Team.

PowerShell Adapter Feedback Provider

This post was originally published on this site

PowerShell Adapter Feedback Provider

We’ve renamed the JSON Adapter Feedback Provider to PowerShell Adapter Feedback Provider! We
heard some good feedback that the name wasn’t as descriptive to what the feedback provider does so
we’ve changed it to be more consistent with its functionality.

The Microsoft.PowerShell.PSAdapter is a module that identifies scripts and tools on the user
machine that can help users more convert native command output into PowerShell objects. We designed
this as a tool to help you discover what tools and scripts are available to help you convert native
output to PowerShell objects.

Note


Feedback Providers are an experimental feature of 7.4-preview3+ and so you will be required to use one of the 7.4 previews for JSON Adapters to work and have `PSFeedbackProvider` experimental feature enabled .

Installing PowerShell Adapter Feedback Provider

The release is available from the PowerShell Gallery.

Use the following command to install using PowerShellGet v2.x:

Install-Module -Name Microsoft.PowerShell.PSAdapter -AllowPrerelease

If you are using PSResourceGet, you can use the following command:

Install-PSResource -Name Microsoft.PowerShell.PSAdapter -AllowPrerelease

To use it you must import the module into your session:

Import-Module Microsoft.PowerShell.PSAdapter

We encourage you to include this command in your $PROFILE so that it’s loaded in every PowerShell
session you start.

What are PowerShell Adapters?

A PowerShell Adapter is a script that converts the text output of a native executable and converts
it to PowerShell objects. The PowerShell Adapter module is a feedback provider that identifies these
scripts and provides suggestions when you run the native command without any adapter script. You can
read more about feedback providers in our blog post, What are feedback providers?.

You can make PowerShell Adapters for any command. Just use the exact name of the command as the
prefix to the script so that the module can identify the script and suggest it. For example, you
must name the script <name of command>-adapter.ps1 so that the PowerShell Adapter can identify it
as a adapter script. This script’s file location must included in your $env:PATH variable to be
found.

Creating an Adapter

For example, you want to use the macOS command vm_stat like a PowerShell object. Create a file
called vm_stat-adapter.ps1 and add the location of this file to your $env:PATH variable. The
PowerShell Adapter Feedback Provider will identify it as a possible suggestion for vm_stat.

Here is an example PowerShell Adapter for vm_stat:

[CmdletBinding()]
param ( [Parameter(ValueFromPipeline=$true)][string]$inputObject )
BEGIN {
    $h = @{}
}

PROCESS {
    if ( $inputObject -match "^Mach Virtual") {
        if ($inputObject -match "page size of (d+) ") {
            $h['PageSize'] = [int]$matches[1]
        }
    }
    else {
        $k,$v = $inputObject -split ":"
        $AdjustedK = ($k -replace "[ -]","_").trim() -replace '"'
        $AdjustedV = "$v".Trim() -replace ".$"
        $h[$AdjustedK] = [int64]$AdjustedV
    }
}

END {
    [pscustomobject]$h
}

The following shows the suggestion from the Feedback Provider when you run vm_stat without the
adapter script:

Screenshot showing vm_stat suggestions.

For another example, we can create a PowerShell Adapter for the df utility using the TextUtility
PowerShell module. We just need to create a df-adapter.ps1 script and include the following:

$input | ConvertFrom-TextTable -ConvertPropertyValue

DF utility adapter

Support for jc

The JSON Converter, jc, is a command line utility that converts text output to JSON for variety of
command line tools. The PowerShell Adapter module can suggest using jc as an adapter if the user
has it installed. When you use a command supported by jc, the PowerShell Adapter Feedback Provider
suggests using jc piped to ConvertFrom-JSON.

You can find instructions on how to install jc and more details about the tool in their
source code repository. When jc supports the native command, this can be the simplest way
to convert the output without needing to write a PowerShell Adapter. You can see this suggestion in
the previous screenshot for the df example.

The jc command supports many native commands, however, the Feedback Provider only provides jc
suggestions for the following commands:

"arp", "cksum", "crontab", "date", "df", "dig", "dir", "du", "file", "finger",
"free", "hash", "id", "ifconfig", "iostat", "jobs", "lsof", "mount", "mpstat",
"netstat", "route", "stat", "sysctl", "traceroute", "uname", "uptime", "w", "wc",
"who", "zipinfo"

Also, you need to use the appropriate parameters with your native command for jc to work properly.
For example, if you want to use jc with uname, you need to use uname -a because that produces
the output that jc expect to convert to JSON.

Predictive IntelliSense Support

We’ve also added Predictive IntelliSense support for the PowerShell Adapter feedback provider. With
Predictive IntelliSense enabled, the PowerShell Adapter Feedback Provider provides suggestions that
Predictive IntelliSense will show you on the command line. This makes it easy to try immediately,
rather than manually running the suggestion.

Screenshot showing predictive intellisense support

Feedback

We really appreciated the feedback we got on the first announcement of this tool and would love to
continue getting great feedback! The GitHub repository for this tool is still named
JSONAdapters, however the module name is Microsoft.PowerShell.PSAdapter and any reference to
this tool will be PowerShell Adapters going forward. You can submit any feedback to the
JsonAdapter repository.

Thank you so much!

Steven Bucher

PowerShell Team

The post PowerShell Adapter Feedback Provider appeared first on PowerShell Team.

PSResourceGet Preview 24 is Now Available

This post was originally published on this site

Microsoft.PowerShell.PSResourceGet is a continuation of the PowerShellGet 3.0 project. The latest preview release of this module under the new name is now available on the PowerShell Gallery. This release contains improved publish support, new aliases and many bug fixes. This is the last planned preview release before we release a “Release Candidate (RC)” of the module. From there we don’t expect to make any changes before we make the module “Generally Available (GA)”.

How to install the module

To install from PSResourceGet previews (which is included in PowerShell 7.4 Preview 4)

Install-PSResource Microsoft.PowerShell.PSResourceGet -Prerelease

To install from PowerShellGet 2.2.5

Install-Module -Name Microsoft.PowerShell.PSResourceGet -AllowPrerelease

What is included in this preview

For the purposes of this blog post, this list includes changes from both beta23 and beta24.

New Features

  • *-PSResourceRepository -Uri now accepting PSPaths
  • Add aliases for Install-PSResource, Find-PSResource, Update-PSResource, Publish-PSResource (‘isres’,’fdres’,’udres’,’pbres’)
  • Add support for NuGet.Server application hosted feeds
  • Add Import-PSGetRepository function to import existing v2 PSRepositories into PSResourceRepositories
  • Add ‘Get-PSResource’ alias to ‘Get-InstalledPSResource’
  • Add -ApiVersion parameter to Set-PSResourceRepository
  • Add support for FindNameGlobbing scenarios (i.e -Name az*) for MyGet server repository (V3)
  • Support Credential Persistence for Publish-PSResource
  • Support publishing with a prerelease dependency

Bug Fixes

  • Better error handling for scenario where repo ApiVersion is unknown and allow for PSPaths as URI for registered repositories
  • Bug fix for Uninstall to remove older versions of a package that are not a dependency
  • Bug fix for Publish finding prerelease dependency versions
  • Fix pagination for V3 search with globbing scenarios
  • Bug fix for publishing with ExternalModuleDependencies
  • Update Save-PSResource -Path param so it defaults to the current working directory
  • Allow environment variables in module manifests (Thanks @ThomasNieto!)
  • Updating prerelease version should update to latest prerelease version
  • Enable UNC Paths for local repositories, source directories and destination directories (Thanks @FriedrichWeinmann!)
  • Bug fix for version parsing in Publish-PSResource
  • Bug fix for Get-InstalledPSResource returning type of scripts as module
  • Bug fix for finding all versions of a package returning correct results and incorrect “package not found” error
  • Bug fix for saving module dependencies
  • Add parameters to Install-PSResource verbose message
  • Bug fix for parsing required modules when publishing
  • Bug fix for saving dependency modules in version range format
  • Bug fix for updating to a new version of a prerelease module
  • Set-PSResourceRepository run without -ApiVersion paramater no longer resets the property for the repository
  • Many error handling updates

Breaking Change

  • Update to Find-PSResource to return packages from all criteria matching repositories, in priority order, by default.

For a full list of changes please refer to the changelog.

Documentation Updates

As a part of our efforts with this module we have also been updating the documentation for this module. We recently updated the documentation on supported repositories to include more information on how to publish. Please check out the documentation and give us feedback in this repository so we can make improvements.

We also recently added an examples folder to our repository with examples for the expected behavior of Find and Install.

How to give feedback and Get Support

We cannot overstate how critical user feedback is at this stage in the development of the module. Feedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.

In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our GitHub repository.

Sydney

PowerShell Team

The post PSResourceGet Preview 24 is Now Available appeared first on PowerShell Team.

Announcing PowerShell Crescendo 1.1.0-RC1

This post was originally published on this site

We’re pleased to announce the release of PowerShell Crescendo 1.1.0-RC1. Crescendo is a
framework to rapidly develop PowerShell cmdlets for common command line tools, regardless of
platform. This release includes improved support for PSScriptAnalyzer, improvements to error
handling, and the addition of ExcludeAsArgument parameter property.

This is a community driven release built from the many suggestions and requests received directly or
from our Github. Thank you PowerShell Community for your adoption and suggestions!

The Release Candidate is now available for download on the PowerShell Gallery.

Installing Crescendo

Requirements:

  • Microsoft.PowerShell.Crescendo requires PowerShell 7.2 or higher

To install Microsoft.PowerShell.Crescendo:

Install-Module -Name Microsoft.PowerShell.Crescendo -AllowPreRelease

To install Microsoft.PowerShell.Crescendo using the new PowerShellGet v3:

Install-PSResource -Name Microsoft.PowerShell.Crescendo -PreRelease

Highlighted features

This Release Candidate includes many fixes and suggestions. Here are just a few of the highlights
added for this release.

Using ScriptAnalyzer with exported module generates a ton of output

Using PSScriptAnalyzer on a Crescendo generated module could result in several violations of the
PSAvoidTrailingWhiteSpace rule. This was due to an additional trailing space after generated
commands. The code generator for Crescendo has been updated to remove the trailing whitespace.

Increase UX of Crescendo-generated cmdlets

Crescendo is designed to pass parameters defined in the configuration as arguments to the native
application. There are times when you may wish to pass a parameter to the output handler but not the
native application. To enable this, a new boolean parameter property ExcludeAsArgument set to
true prevents the argument from being sent to the native application. The default is false.

"Parameters": [
        {
            "Name": "P1",
            "ParameterType": "string",
            "ExcludeAsArgument": true,
            "Mandatory": false,
            "Description": "Variable not sent to native app"
        }
    ],

CrescendoNativeErrorQueue and -ErrorAction Stop

Handling errors using Pop-CrescendoNativeError may include multiple errors from the same
execution. This can happen when the cmdlet and the native command both emit an error that gets
enqueued by Crescendo. The architecture is modified so that the error queue is now local to the
cmdlet.

Crescendo should probably set $PSNativeCommandUseErrorActionPreference = $false

By default, $PSNativeCommandUseErrorActionPreference is set to true. This causes Crescendo to
produce an additional error record for every error. To prevent this, Crescendo changes the value to
false for each generated cmdlet.

Add the current version of the Crescendo module

Crescendo modules now include version and schema metadata at the top of the module.

# Module created by Microsoft.PowerShell.Crescendo
# Version: 1.1.0
# Schema: https://aka.ms/PowerShell/Crescendo/Schemas/2022-06
# Generated at: 07/13/2023 12:48:59

More information

To get started using Crescendo, check out the documentation.

Future plans

We value your ideas and feedback and hope you give Crescendo a try. Stop by our
GitHub repository and let us know of any issues you find or features you would like added.

The post Announcing PowerShell Crescendo 1.1.0-RC1 appeared first on PowerShell Team.

Desired State Configuration (DSC) Planning Update

This post was originally published on this site

Desired State Configuration (DSC) Planning Update – August 2023

Hey DSC enthusiasts! We’re bursting with excitement to share new information about the plans for Desired State Configuration (DSC). First off, we’d like to extend a massive thank you to our amazing community for your feedback. Your input helps shape the future of DSC, and we’re grateful for your continued support.

A big shout-out to the Dev Home and WinGet teams for announcing new features at the recent Build conference. These new features, documented here, are the first solutions to leverage capabilities of the new DSC platform, and we plan for them to be the first of many.

We want to give you a sneak peek at the foundational tenets planned for the new DSC vision, and we’re looking forward to refining them with your help.

What’s in the Pipeline?

As we move forward, we want to focus on the following tenets as the foundation of our new DSC vision:

  • Compatibility: We plan to ensure that existing community resources work without changes, including those written as PowerShell script and classes. Class-based resources are recommended but not required.
  • Transparency: Our new project repo is now public on GitHub, allowing the community to view and submit issues. We are intentionally making the project open from an early stage of development so the community has opportunity to give early feedback.
  • Cross-platform Support: In the open-source project, we plan to compile builds that work on Windows, Linux, and macOS.
  • Language Flexibility: Resource authors can write DSC resources in any interpreted or compiled languages accessible by the command line, including PowerShell. MOF as a format for configurations is no longer supported and is being replaced with the industry accepted JSON and/or YAML. JSON schema replaces MOF schema for resources while existing PowerShell script based resources that have MOF schema will be supported as-is.
  • Common Concepts: We aim to support or provide extensibility for concepts like composability, re-use, reboots, secrets, dependencies, and runas.
  • Low Barrier To Entry: We plan to carry forward the concept of simple “one-liner” authoring previously used by Script/nxScript, while making it easier for newcomers to adopt best practices like test automation.
  • Isolated Network Usability: We intend to make the command-driven platform usable in isolated networks. While we do not currently plan to reintroduce LCM, we will continue as an extensible platform that any configuration solution can leverage.
  • Environmental Dependencies: Our plans include allowing users to express environmental dependencies as assertions when authoring configurations. Examples of assertions could be scenarios like detecting when a machine needs to be rebooted before taking action.
  • Resource Input/Output: We’re working towards enabling users to pass output from one resource as input to another when authoring configurations.

It is important to note that this is an early preview of the next generation DSC, so we expect breaking changes to occur based on feedback during development.

Next Steps

We know this blog post raises many questions, and we’re eager to address them! We have requested an agenda item during the next DSC community call on August 9th, 2023, to discuss the vision and answer questions. Details about DSC community calls are published on the DSC community website.

For detailed how-to information, visit our GitHub repository. The project repository is where we plan to publish builds for testing as releases. Keep in mind that this is an ‘alpha’, akin to a ‘developer preview’ and not ready for production.

Please submit issues in GitHub to send feedback, even if it’s a request or idea. To get started, we would love to hear your requirements around:

  • Resource authoring experiences and tools
  • Ease of integration with your favorite configuration management solution
  • The new configuration syntax

Together, we’ll shape the future of Desired State Configuration.

Make it so!

The post Desired State Configuration (DSC) Planning Update appeared first on PowerShell Team.

Microsoft.PowerShell.TextUtility module updates

This post was originally published on this site

TextUtility module gets new functionality

We have recently released another preview of the TextUtility module. This module is a collection of tools that
are meant to help with working with text content.

Installing the module

You can install this module from the PowerShellGallery with PowerShellGet via:

Install-Module -Name Microsoft.PowerShell.TextUtility -AllowPrerelease

Or you can install it with PSResourceGet via:

Install-PSResource -Name Microsoft.PowerShell.TextUtility -Prerelease

ConvertFrom-TextTable

The most recent pre-release of Microsoft.PowerShell.TextUtility
has some new exciting functionality.
The new ConvertFrom-TextTable cmdlet allows you to take tabular text
and convert it into objects.
Also, there is a way to convert some of types of those objects into something other than a string.
Using the -ConvertPropertyValue parameter will change the value of the property to a strongly typed value.
This means you can do the following:


PS> df | select -first 6 | convertfrom-texttable -ConvertPropertyValue |Ft                       

Filesystem     512-blocks     Used  Available Capacity  iused      ifree %iused Mounted_on
----------     ----------     ----  --------- --------  -----      ----- ------ ----------
/dev/disk4s1s1 3907805752 17699080 1242895000 2%       355382 4291123926 0%     /
devfs                 462      462          0 100%        800          0 100%   /dev
/dev/disk4s3   3907805752  3676600 1242895000 1%         3745 6214475000 0%     /System/Volumes/Preboot
/dev/disk4s5   3907805752  4194376 1242895000 1%            2 6214475000 0%     /System/Volumes/VM
/dev/disk4s6   3907805752    19992 1242895000 1%           19 6214475000 0%     /System/Volumes/Update

PS> df | select -first 6 | convertfrom-texttable -ConvertPropertyValue |?{$_.available -lt 10}|Ft

Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted_on
---------- ---------- ---- --------- -------- ----- ----- ------ ----------
devfs             462  462         0 100%       800     0 100%   /dev

ConvertFrom-TextTable also allows you to specify where the header line is defined, or skip lines until you get to where the data starts.
Additionally, it is possible to take the text output and explicitly create properties by defining where a column starts.

PS> $string = $("a".."z";"A".."Z";0..9) -join ""                                                      
PS> 1..10 | %{$string}|convertfrom-texttable -noheader -columnoffset 0,15,23,40,55 | ft

Property_01     Property_02 Property_03       Property_04     Property_05
-----------     ----------- -----------       -----------     -----------
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789
abcdefghijklmno pqrstuvw    xyzABCDEFGHIJKLMN OPQRSTUVWXYZ012 3456789

Finally, you can also emit the data as JSON with the -AsJson parameter:

PS> who -p | %{$_.trim()} | convertfrom-texttable -noheader -AsJson  
{ "Property_01": "james", "Property_02": "console", "Property_03": "Jun", "Property_04": "22", "Property_05": "08:34" }
{ "Property_01": "james", "Property_02": "ttys016", "Property_03": "Jun", "Property_04": "22", "Property_05": "10:00" }
{ "Property_01": "james", "Property_02": "ttys017", "Property_03": "Jun", "Property_04": "22", "Property_05": "14:42" }
{ "Property_01": "james", "Property_02": "ttys004", "Property_03": "Jun", "Property_04": "22", "Property_05": "22:08" }
{ "Property_01": "james", "Property_02": "ttys025", "Property_03": "Jun", "Property_04": "23", "Property_05": "00:38" }

Next Steps

This is still in pre-release and we know that there is still work to be done.
For example, the parser will create an object out of the header/data separator.
This is a little trickier than at first it would seem.
The text is inspected and columns width is decided based on the inspected text.
These header/data separator lines help the parser understand where the columns are separated.
This means we can’t just toss them out as the text is being read.
I’m sure you’ll find more things that we can do,
and we would love to get your feedback on this new cmdlet so please give this module a try.
Please submit your feedback to the repo directly via the issues tab, here.

Thanks so much!

Jim Truher

PowerShell Team

The post Microsoft.PowerShell.TextUtility module updates appeared first on PowerShell Team.

JSON Adapter Feedback Provider

This post was originally published on this site

JSON Adapter Feedback Provider Release

We are excited to announce the first release of our JSON Adapter Feedback Provider! If you are
unfamiliar with what feedback providers are, check out this blog describing them, here.

Installing JSON Adapter Feedback Provider

The release is available from the PowerShell Gallery.

Use the following command to install JsonAdapter using PowerShellGet v2.x:

Install-Module -Name Microsoft.PowerShell.JsonAdapter -AllowPrerelease 

If you are using PSResourceGet, you can use the following command:

Install-PSResource -Name Microsoft.PowerShell.JsonAdapter -AllowPrerelease

To use it you will need to import the module into your session via:

Import-Module Microsoft.PowerShell.JsonAdapter

We encourage you to include the import message in your $PROFILE so it can persistently be loaded
in every PowerShell session you start. If you have Visual Studio Code installed, type
code $PROFILE to edit your profile or use your choice of editor.

What are JSON Adapters?

A JSON adapter is a script that can parse the text output of a native executable and convert it to
JSON. Once the output is in a machine readable format like JSON, you can use ConvertFrom-JSON
cmdlet to make any native executable behave like a PowerShell object. JSON adapters can be made for
any command, it is just required to use the exact name of the command as the prefix to the script.
The script will have to be named like so <name of command>-json.ps1 to be identified by the JSON
adapter utility. This script’s file location must also be added to your $env:PATH variable to be
found.

Creating a JSON Adapter

For example, say you are on a Mac and want to use the command vm_stat like a PowerShell object. If
you add the following to a file called vm_stat-json.ps1 and add the location of this file to your
$env:PATH variable, the JSON Adapter feedback provider will identify it as a possible suggestion
for vm_stat.

[CmdletBinding()]
param ( [Parameter(ValueFromPipeline=$true)][string]$inputObject )
BEGIN {
    $h = @{}
}

PROCESS {
    if ( $inputObject -match "^Mach Virtual") {
        if ($inputObject -match "page size of (d+) ") {
            $h['PageSize'] = [int]$matches[1]
        }
    }
    else {
        $k,$v = $inputObject -split ":"
        $AdjustedK = ($k -replace "[ -]","_").trim() -replace '"'
        $AdjustedV = "$v".Trim() -replace ".$"
        $h[$AdjustedK] = [int64]$AdjustedV
    }
}

END {
    [pscustomobject]$h
}

 

This is what the experience looks like in the shell.

VM stat screenshot

JC

JC or JSON Converter, is a command line utility that can convert text to JSON for variety of command
line tools. You can find instructions on how to install jc and a full list of supported commands
on the repo of jc. It can be a great tool to use to convert the outputs without writing a JSON
Adapter yourself. The JSON Adapter module supports using jc as a JSON Adapter if the user has it
installed. This means if you have the jc utility installed and use a command that is supported by JC, the JSON
Adapter feedback provider will suggest using JC piped to ConvertFrom-JSON.

It is important to note that not all jc supported utilities are supported. The list of supported commands is:

"arp", "cksum", "crontab", "date", "df", "dig", "dir", "du", "file", "finger",
"free", "hash", "id", "ifconfig", "iostat", "jobs", "lsof", "mount", "mpstat",
"netstat", "route", "stat", "sysctl", "traceroute", "uname", "uptime", "w", "wc",
"who", "zipinfo"

Additionally, you will need to use the appropriate parameters that jc requires to work properly. For
example, if you want to use jc with uname, you will need to use uname -a as that is what jc
requires to properly convert the output to JSON.

Predictive IntelliSense Support

We have also added predictive IntelliSense support for the JSON Adapter feedback provider. This
means after a JSON Adapter feedback provider is triggered, as you type the command name again,
Predictive Intellisense will suggest the feedback command to you. This is a great way to easily try
the suggestion after a JSON Adapter feedback provider is triggered.

screenshot showing predictive intellisense support

Feedback

As this is our very first release, we know there may be issues that arise. We definitely look
forward to your feedback and suggestions! You can provide feedback on the repo for this project
here.

Jim Truher and Steven Bucher

PowerShell Team

The post JSON Adapter Feedback Provider appeared first on PowerShell Team.

What are Feedback Providers?

This post was originally published on this site

We introduced a new experimental feature back in PowerShell v7.4.0-preview.2+ called
PSFeedbackProvider. This blog outlines what this experimental feature is, how to use it and
describes different feedback providers we have already created.

Installing the PowerShell Preview and enabling Feedback Providers

You can install the latest 7.4 preview via our GitHub page here. If you are on Windows you can
download via the Microsoft store here.

Unless configured differently, the previews should have all experimental features enabled by deafult
but in case they are not enabled you can check and enable them by using the following commands:

Checking experimental features enabled:

Get-ExperimentalFeature

Enabling experimental feature:

Enable-ExperimentalFeature -Name PSFeedbackProvider

You will also have to enable the experimental feature PSCommandNotFoundSuggestion to get enable
the built in feedback provider.

Enable-ExperimentalFeature -Name PSCommandNotFoundSuggestion

Note


You must restart your PowerShell session to enable experimental features.

Why have we created Feedback Providers

After we created PowerShell Predictive IntelliSense, we realized that no matter how hard we can try
to be “preventative” of errors, they will still occur. This made us think there was a better way to
give the users more feedback to their errors so they could recover quicker from them.

After prototyping and seeing how great it could work for errors, we got thinking that maybe we can
help inform and teach users better practices to the shell and thus we expanded feedback providers to
successful executions and comments.

What are Feedback Providers?

Feedback Providers are PowerShell modules that utilize the IFeedbackProvider interface to give
feedback and suggestions after the shell users have attempted to execute something. Feedback
providers can trigger upon three different interactive scenarios:

  • Errors
  • Success
  • Comments

This means after the user has hit enter, Feedback Providers can trigger and know what scenario the
user has faced.

Built in Feedback Provider

We have created a built in feedback provider named General. This triggers on the CommandNotFound
exception error and gives the user suggestions on what command they may have meant to type from list
of commands already installed in the users $env:PATH. Both native commands and PowerShell cmdlets
will be suggested if they are installed.

You have may seen something similar to this before in previous versions of the
PSCommandNotFoundSuggestion experimental feature. We have given the UX an upgraded and turned this
into a feedback provider!

This is the old PSCommandNotFoundSuggestion experience:

Image SuggestionFramework png

This is the same feature but with the new feedback provider model:

Image CommandNotFoundFeedbackProvider

Command-Not-Found Feedback Provider

We have created an additional feedback provider that we call the command-not-found feedback
provider. This utilizes the command-not-found utility tool that is defaulted on Ubuntu systems.
This feedback provider will trigger when the user has attempted to execute a command that is not
installed on the system but will give the user suggestions on how to install the command on their
system using apt. This is only compatible with Linux systems where the command-not-found utility
tool has been installed.

Image FeedbackProvider

 

Another thing we did with this feedback provider is that we have it subscribed to the
ICommandPredictor interface so that it can give it suggestions directly to PowerShell Predictive
IntelliSense. This way as you start typing a suggestion, you can more quickly accept the suggestion.

Image commandnotfound png

We have open sourced this feedback provider so you can take a look at how we have implemented it
here. You can install this feedback provider from the PowerShell Gallery via this command:

Install-Module -Name command-not-found

Or if you are using the latest version of PSResourceGet, you can use this command:

Install-PSResource -Name command-not-found

You will need to import the module to enable the feedback provider:

Import-Module -Name command-not-found

We recommend you save this in your PowerShell $PROFILE so that it is always available to you.

What’s next with Feedback Providers?

We are still under rapid development with feedback providers so there may be changes to them in the
future! Due to the changes we are doing to the feedback provider, we will be publishing
documentation on how to create your own once we have finalized some design changes for creating the
providers.

In the meantime if you have any ideas on how we can make this experience best work for your
PowerShell workflow, please let us know in the issues tab of our PowerShell repo!

We are excited to be sharing more about feedback providers in the near future.

Thanks

Steven Bucher

The post What are Feedback Providers? appeared first on PowerShell Team.

PowerShellGet in PowerShell 7.4 Updates

This post was originally published on this site

Version 3 previews of PowerShellGet will begin shipping in PowerShell 7.4 previews in June (preview 5) with the following updates. These changes include important plans to address migration and compatibility, and we would like to request feedback.

  • The module name “PowerShellGet” for version 3 (-PSResource cmdlets) will change to “Microsoft.PowerShell.PSResourceGet” begining with the next release (beta22).
  • PowerShell v7.4 (LTS) will ship PowerShellGet v2.2.5 and PSResourceGet v3.0.x, side-by-side. This will help us get telemetry about usage of PSResourceGet. No compatibility layer will be shipped, meaning we will not wrap version 3 commandlets with version 2 names. This allows current scripts to work as-is, with or without fully qualified cmdlet names, while still allowing customers to test the new commandlets.
  • Customers can use -PSResource cmdlets for perf improvements and new features. No new feature work will be done in -Modulecmdlets.
  • In the first preview of PowerShell v7.5 we will include CompatPowerShellGet renamed as PowerShellGet v3.0.0, in addition to publishing the latest PSResourceGet module. In PowerShell v7.5 we will not ship PowerShellGet v2.2.5.
  • In PowerShell v7.5 we plan to ship PowerShellGet v3.0.0 and the latest stable version of PSResourceGet, side-by-side.
  • We will get community feedback about the compatibility layer that will help use decide on the final plans for PowerShell v7.5.
  • We plan to ship PSResourceGet in addition to current PowerShellGet 1.0.0.1 in future builds of Windows so PSResourceGet can be made available by default in Windows PowerShell 5.1.
  • We also plan to improve the experience of updating PowerShellGet/PSResourceGet in prior releases of Windows.
  • We will update the PowerShellGet repository name on GitHub to reflect the new PSResourceGet name.

We would greatly appreciate your thoughtful feedback on these plans while there is still time to consider changes. Please comment on this github issue.

Considerations for this decision

We appreciate the feedback we have already been given by the community, at PowerShell events, by MVP’s, and by our peers. Some of the key factors that played into this decision were

  • PowerShell 7.4 is an LTS release. We are merging releases later in the preview cycle than we wanted. We now need to be especially cautious about breaking changes that could impact existing scripts/automation.
  • Using telemetry to track adoption of PowerShellGet v3 (now PSResourceGet) will help inform when we have an appropriate level of usage relative to feedback, to confirm public validation before release.
  • In the future, we would like to be able to end new feature work for PowerShellGet v2 due to support difficulties with OneGet(PackageManagement) and focus on PSResourceGet. We recognize it will take time for mass adoption of PSResourceGet, so we will be moving cautiously.
  • For a deeper look into other options we explored please refer to this github issue.

We look forward to reviewing community feedback!

Sydney PowerShell Team

The post PowerShellGet in PowerShell 7.4 Updates appeared first on PowerShell Team.

PowerShellGet 3.0 Preview 21

This post was originally published on this site

We are excited to announce that an update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery!

How to Install PowerShellGet 3.0 Preview 21

Prerequisites

Please ensure that you have the latest (non-prerelease) version of PowerShellGet and PackageManagement installed. To check the version you currently have installed run the command Get-InstalledModule PowerShellGet, PackageManagement

The latest version of PowerShellGet is 2.2.5, and the latest version of PackageManagement is 1.4.7. To install the latest versions of these modules run the following: Install-Module PowerShellGet -Force -AllowClobber

Installing the Preview

To install this preview release side-by-side with your existing PowerShellGet version, open any PowerShell console and run: Install-Module PowerShellGet -Force -AllowPrerelease

What to expect in this update

This update moves local repositories off of the NuGet APIs, this change was made to enable future improvements such as parallelization. This update also includes a number of bug fixes.

In this update we also made the decision to hold off on merging PowerShellGet previews into PowerShell 7.4 previews until June. This decision was made because we want to be really intentional about our decision making process with merging, or not merging, the compatibility module into PowerShellGet. At this point in time we are exploring a number of different options regarding module compatilibity to participate in this converation please refer to this issue.

Features of this release

New Features

  • Move off of NuGet client APIs for local repositories

Bug Fixes

  • Update properties on PSResourceInfo object to Remove PackageMangementProvider property and make PowerShellGetFormatVersion property private
  • Rename cmdlets
    • Get-PSResource -> Get-InstalledPSResource
    • New-PSScriptFileInfob -> New-PSScriptFile
    • Test-PSScriptFileInfo -> Test-PSScriptFile
  • Fix ValueFromPipelineByPropertyName on Save, Install
  • add Help message for mandatory params across cmdlets
  • Fix version range bug for Update-PSResource
  • Fix attribute bugfixes for Find and Install params
  • Correct Unexpected spelling of Unexpected
  • Resolve bug with Find-PSResource -Type Module not returning module

Features to Expect in Coming Preview Releases

This module is feature complete but we are continuing to make bug fixes. For the full list of issues for our next preview release please refer to our GitHub project.

How to Track the Development of this Module

GitHub is the best place to track the bugs/feature requests related to this module. We have used a combination of projects and labels on our GitHub repo to track issues for this upcoming release. We are using the label Resolved-3.0 to label issues that we plan to release at some point before we release the module as GA (generally available).

Timeline/Road Map

Expect to see preview releases as bug fixes are made. User feedback will help us determine when we can have a Release Candidate version of the module which will be supported to be used in production. Based on user feedback, if we believe the 3.0 release is complete, then we will publish a 3.0 version of the module as Generally Available. Since these milestones are driven by quality, rather than date, we can not offer an exact timeline at this point.

How to Give feedback and Get Support

We cannot overstate how critical user feedback is at this stage in the development of the module. Feedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.

In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our GitHub repository.

Sydney Smith

PowerShell Team

The post PowerShellGet 3.0 Preview 21 appeared first on PowerShell Team.