Why pwsh Was Chosen For PowerShell Core

Intro

With the release of PowerShell Core 6.0.0-beta.9 the binary for PowerShell Core was renamed from powershell.exe and powershell on Windows and Linux/Unix/macOS respectively to pwsh.exe and pwsh. This major change has drained the pitchfork and torch emporiums of their stock as PowerShell users from all over the globe have taken to internet forums, twitter, slack, and the PowerShell repo to voice their opposition and disbelief in this change. The responses range from minor annoyance to expletive heavy diatribes.

It's clear that many PowerShell users are not happy with this change.

So why did the PowerShell Team decided to make such and unpopular change? There are several reasons the change was necessary and for why pwsh was chosen. I will attempt my best here to explain them all.

As you read, please keep in mind that I'm not a Microsoft employee nor am I a member of the PowerShell Team. I'm just a community contributor with collaborator access to the GitHub repo. I don't have any special insider knowledge, but I do follow the repo and PowerShell Core very closely. I am speaking to you as a fellow member of the community as someone with a decent insight into the project, not as an outright authority on all things PowerShell.

New PowerShell Core Feature: Basic and OAuth Authentication for Invoke-WebRequest and Invoke-RestMethod

Intro

PowerShell has always supported Basic authentication on Invoke-WebRequest and Invoke-RestMethod via the -Credential parameter. Those of you who have tried to use it on any modern APIs are probably scratching you head at what I just wrote. You probably know full well that the -Credential parameter is not sending Basic Authentication credentials when you expect it to. But it's true, Basic authentication has been there all along. The problem is that PowerShell will only send credentials if challenged.

This is a problem for accessing modern API's, especially for requesting OAuth Tokens from authentication endpoints. Modern APIs often do not issue 401 status codes with WWW-Authenticate headers. This results in the Web Cmdlets not issuing credentials to the remote server even though they were supplied. Modern API's expect you to present your credentials explicitly without being challenged first. This has resulted in a common frustration and feature request.

Additionally, the Web Cmdlets did not have any native support for OAuth bearer tokens. This means that all calls to APIs requiring OAuth tokens required passing an Authorization header. Since many OAuth grant flows require the client ID and client secret be sent as Basic authentication without a challenge, the entire OAuth process becomes a manual task.

I have run into this myself with the PSRAW and PSMSGraph projects. In both projects I have created wrapper functions around Invoke-WebRequest and Invoke-RestMethod that provide OAuth capabilities and handle the conversion of PSCredential to Basic Authentication. I have long wish this functionality was native to the cmdlets.

I'm pleased to announce that beginning with PowerShell Core 6.0.0-Beta.9, Invoke-WebRequest and Invoke-RestMethod  natively support explicit Basic and OAuth authentication.

If you want this functionality now, build the current master branch or pickup the nightly build. this was added in Pull Request #5052.

-NoTypeInformation is Now Default For Export-Csv and ConvertTo-Csv in PowerShell Core

Intro

On Monday morning I opened the PowerShell slack and started to catch up on the conversations I missed. The most recent conversation that morning was someone, yet again, asking how to get rid of the annoying first line in the output from Export-Csv. This is such a common question and an issue that trips up many PowerShell novices. I've probably answered this question several dozen times on /r/PowerShell. It also caused me grief when I was just starting out with the language.

This prompted me to ask myself and the slack channel "Does anyone actually use the default behavior of including the type information?" My gut and the few users online at the time told me no. So I created an Issue in the PowerShell repo then asked for feedback from /r/PowerShell, Twitter, and Slack. The result was 175 thumbs up, no thumbs down, and not a single person coming out in support of the default behavior.

Since the change is a breaking change, the issue went before the PowerShell Committee Wednesday and was ultimately approved. I quickly made my PR and early this morning the PR was merged to master. That's right: Starting with PowerShell 6.0.0-Beta.9 -NoTypeInformation will be the default behavior on Export-Csv and ConvertTo-Csv.

If you want this feature sooner, rather than later, you can either build the current master or pick up tomorrow's nightly build.

I use ConvertTo-Csv for all of my examples in this post for convenience. There is little difference between it and Export-Csv besides the fact that one puts a string in the output stream and the other in a file. They both share the same base class where this change was implemented so they both share the same new behavior.

Hacktoberfest 2017 and PowerShell

Image source: https://hacktoberfest.digitalocean.com/

Intro

Hacktoberfest 2017 is upon us! Hacktoberfest is a month long celebration of open source software held by DigitalOcean in partnership with GitHub. The basis are thus:

1. Go to https://hacktoberfest.digitalocean.com/
2. Register with your GitHub account
3. Make Pull requests in GitHub Repositories
4. Make open source better
5. Get a t-shirt (see site for details)

I posted about this recently on Reddit and I had many questions about what the bar is to become a contributor. I figured this was a fitting blog topic so I will cover it here.