The latest preview of PowerShellGet is now available on the PowerShell Gallery. In this new preview version of PowerShellGet, PowerShellGet is a compatibility module that allows use of PowerShellGet 2.x (and below) cmdlet syntax with PSResourceGet functionality by making a best effort mapping between the cmdlet interfaces of both versions of the module. This module is a continuation of the CompatPowerShellGet project, but will now be shipping under the PowerShellGet module name.

How to install the module

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

Install-PSResource PowerShellGet -Prerelease

To install from PowerShellGet 2.2.5

Install-Module -Name PowerShellGet -AllowPrerelease -Force -AllowClobber

Note that Microsoft.PowerShell.PSResourceGet is also required to use this module,but it is not listed as a dependency as it is still in prerelease.

Expectations for the module

PowerShellGet is a compatibility module that allows use of PowerShellGet 2.x (and below) cmdlet syntax with PowerShellGet 3.0 (and newer) functionality by making a best effort mapping between the cmdlet interfaces of both versions of the module. For example, if a user has the PowerShellGet module installed and runs the command Install-Module PowerShellGet -AllowPrerelease PowerShellGet module will get auto loaded into the PowerShell Session and will map the command to PSResourceGet syntax Install-PSResource PowerShellGet -Prerelease The command will then be executed by the PowerShellGet 3.0 implementation.

This module is designed so that users will not need to immediately update their scripts in order to update to the latest version of PowerShellGet or to begin taking advantage of the performance improvements already available in PSResourceGet. We still do recommend that authors begin making the changes required to update their scripts to the new cmdlet interface if they would like to take advantage of the new features available in PSResourceGet (described in other blogs).

This compatibility module is designed so that it takes precedence over legacy versions of PowerShellGet. If you have this compatibility module installed and would not like it to be used, you can remove it from the PowerShell session using the Remove-Module command.

Please note that this flow is only possible if the user has both the PowerShellGet module installed and the Microsoft.PowerShell.PSResourceGet module installed. Once PSResourceGet is generally available it will be a dependency of future versions of PowerShellGet.

Timeline

This module is expected to ship in PowerShell 7.5. We expect this module to reach GA in the early PowerShell 7.5 timeframe to maximize opportunity for quality feedback. We do not expect to introduce new features to this module, all new features will be designed in Microsoft.PowerShell.PSResourceGet. Some new features may work in this module as a side effect.

Going forward we do not plan to do any future releases of the CompatPowerShellGet module, all releases will be under the PowerShellGet name.

How to give feedback or get support

This version of the module is still in preview, meaning that bugs are expected. We really appreciate any feedback on the module. If you have any bug reports, questions, or suggestions for features please open up a bug report in the PowerShellGet repository.

Sydney

PowerShell team

The post PowerShellGet 3.0.22-beta22 is now available appeared first on PowerShell Team.

We’re pleased to announce the availability of PowerShell Crescendo 1.1.0. Crescendo is a
framework to rapidly develop PowerShell cmdlets for common command line tools, regardless of
platform.

The release is now available for download on the
PowerShell Gallery.

Making Cmdlets with PowerShell Crescendo

Crescendo is a development accelerator enabling you to rapidly build PowerShell cmdlets that
leverage existing command-line tools. Crescendo amplifies the command-line experience of the
original tool to include object output for the PowerShell pipeline, privilege elevation, and
integrated help information. A Crescendo module replaces cumbersome command-line tools with
PowerShell cmdlets that are easier to use in automation and packaged to share with team members.

The 1.1 GA release includes the following features and benefits:

• Updated schema to support additional features for this release.
• Prevent overwrite of the module manifest and allow for module manifest adaptations.
• Ability to bypass the output handler when the output of the native command doesn’t need to be
  transformed.
• Improved error stream and error handling with Pop-CrescendoNativeError.
• Added ability for parameter values to be translated via key/value pair with ArgumentTransform
  and ArgumentTransformType.
• Improved code generation to reduce PSScriptAnalyzer output.
• Improved error handling by setting $PSNativeCommandUseErrorActionPreference = $false.
• Improved module metadata and added current Crescendo version to the module.

For more information about these changes, see What’s new in Crescendo 1.1.

Installing Crescendo

Requirements:

• Microsoft.PowerShell.Crescendo requires PowerShell 7.2 or higher
• Crescendo generated cmdlets require PowerShell 5.1 or higher

To install Microsoft.PowerShell.Crescendo:

Install-Module -Name Microsoft.PowerShell.Crescendo

To install Microsoft.PowerShell.Crescendo using the new PSResourceGet:

Install-PSResource -Name Microsoft.PowerShell.Crescendo

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 General Availability (GA) appeared first on PowerShell Team.

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

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.

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:

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

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.

"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"

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.

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.

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.

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 (Thanks @DennisL68)
• Increase UX of Crescendo-generated cmdlets (Thanks @steviecoaster)
• CrescendoNativeErrorQueue and -ErrorAction Stop (Thanks @MTI-gh)
• Crescendo should probably set $PSNativeCommandUseErrorActionPreference = $false (Thanks
  JamesWTruher)
• Add the current version of the Crescendo module (Thanks @LaurentDardenne)

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

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

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.

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.

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

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:

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

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.

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.

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.