PowerShell 7.0
devblogs.microsoft.com
devblogs.microsoft.com
I just wish they made the language nicer and more consistent. There are so many weird quirks around functions, modules, scope and classes that make life pretty difficult in larger code bases. I would love to see something closer to C# (or even TypeScript) that still can use cmdlets easily. The current Powershell language to me feels like a weird hack but not something well designed. Typescript and C# have demonstrated that MS can design good languages.
This leads me to another complaint. MS is cranking out a lot of useful cmdlets that would also be useful for C# programmers but using them from C# is quite painful.
For example I started appreciating the way output in PS1 works only after using the parallel for each and was floored by how everything fell in place.
Take this from a full time Linux user, if you're not using powershell you're using an inferior shell.
One major downside for cli warriors though- it takes a couple of seconds to start. (at least 6, I don't knoe about 7).
Jeff hello, if it's alright i wanted to discuss the target audience of Powershell.
As I understand Microsoft is currently targeting azure users and enterprise sysadmins. I would like to propose that You add features to it that bash and zsh power users take for granted and target the linux community so that it gets more cred and in the open source hackers community and consequently more usage by regular people. Basically the developers developers developers thing from your old boss...
To be honest, right now I can recall anything I'm missing, fzf works, so does z. I will look at the startup time issue (my biggest one right now, I literally had PS1 as my login shell briefly ) ...
I don't want to make any news here but in a bit, the team will publish a blog articulating where we'll be focusing our next release. I think you'll like the direction we are taking.
Jeffrey Snover [MSFT]
This thing itself seems like a quirk but again I'm not an expert so don't know how this was designed.
If cmdlets were easier to use i would probably have used a proper language like csscript or C# instead of Powershell.
> In PowerShell, the results of each statement are returned as output, even without a statement that contains the Return keyword. Languages like C or C# return only the value or values that are specified by the return keyword.
I don't want all output, no, please, I don't want it. I want something specific and not all the junk around it. So you have to turn into ugly measures like out-nulling everything or searching through your output because there is always possibility that some commandlet outputed something you were not expecting and it will return before the value you actually wished to returned.
And classes are nice and all, but lot's of stuff are not compatible PowerShell 5. And there is also the added complexity.
https://docs.microsoft.com/en-us/powershell/module/microsoft...
Reading through the examples of the unexpected behavior in so many cases is flabbergasting.
Interesting note - it is also the reason why PowerShell was able to adopt the more natural Verb-Noun model for cmd naming. In Unix, this would produce a huge # of files OR and you couldn't do "VERB NOUN" because then you would have to multiplex on the VERB. Unix's "NOUN VERB" is the result.
BTW - VMS DCL stepped on all these rakes which is why it is have VERB/NOUN and half NOUN/VERB. A complete mess.
Jeffrey Snover [MSFT]
Alacritty is a terminal - a container that transports user inputs to programs (like shells) and prints program outputs to the screen. The terminal owns the actual graphical window you interact with.
The default terminal on Windows is the Windows Console. Windows comes with two shells, the Command Prompt (cmd.exe) and PowerShell. Both of these run on top of the Windows Console.
There is also a new terminal in development by Microsoft, called the Windows Terminal. It's much more modern due to not having to be backwards compatible.
It's the best native scripting platform you can get on Windows, but some of its primitives (functions, classes) are weird, parallelism (at least in the v5 days) was massively hacky (process-based instead of thread-based through the PSJob abstraction, though you can use native threads if you put in some work) and its syntax and overall behavior makes it feel more like a scripting language than something you'd use to build real apps (even though you can). This makes it a really tough sell to use on MacOS and Linux, even though it's based on .NET Core and you totally could.
I would make a slight correction, Typescript and C# have proven that Anders Hejlsberg can design good languages, not MS.
Honestly, Hejlsberg is like the Midas of programming languages.
That man is a language designing genius.
He is the main designer behind:
Delphi (which inspired VB6, Microsoft's DOMINANT language through the 90's. But it's so similar to Delphi, that you can pretty much credit Hejlsberg for it's success), C#, and Typescript
Sometimes whole companies get credit for the genius of what is really just one or two architects.
When it comes to Apple innovations, it's Jobs
And when it comes to MS language innovations, with the exception of F#, it's Hejlsberg.
I always thought Visual Basic got unfairly mocked because it was a fantastic language and framework for non-computationally expensive workloads.
Delphi, on the other hand, I struggled to enjoy. I really wanted to love Delphi because Pascal was one of my favourite languages but Delphi just didn't gel with me and it's hard to explain why. However Hejlsburg was also the author of Turbo Pascal and that achievement alone deserves to put him in the history books in my opinion.
It's also worth noting that your Apple/Jobs comment should probably acknowledge Steve Wozniak instead.
http://nushell.sh/ is an example of a new (non-POSIX) shell that's trying to be more structured, similar to PowerShell. Thanks to nu's new -c option, it's possible to use nu profitably even if you don't make it your shell. I doubt I'd ever use PowerShell as my system shell on Mac/Linux, but I don't want to close myself off from tools that might be useful for particular tasks or scripts.
Personally, since MS has made Javascript a 1st class citizen on Windows now, it would be nice if Javascript and Typescript were better integrated into PowerShell. It would be nice to have one language to rule them all. I hate the time wasted with context switching. Also, I still hate using PS script. They make a lot of strange style decisions like with method / parameter declaration.
The syntax however should get a lifting, to result in something like C# but with less curly braces.
That thing supports VBScript and JScript out of the box. Most scripts are written in VBS in practice, though.
C# / Java is way too verbose, though almost anything is better than PS script syntax
For instance, it's not straightforward to take a database or XLS document of users and transform that into an Active Directory implementation.
Here is a tool that would help with that: https://github.com/dsccommunity/ActiveDirectoryDsc
Normally you would need to run this on a Windows machine ... but now I am excited at the thought of using it from my mac.
I'm in the middle of doing a rollout of new network infrastructure, VPN, Firewall appliance, Hyper-V hosts, Active Directory, O365 sync, File storage, etc... for small/medium sized business. I am primarily a software/ops consultant, so I like to build infrastructure 'as data' and then use that data to assert the real thing. IE, terraform apply.
tl;dr – with cross platform we're closer to bringing modern ops tools into Windows land which is exciting. WSL is useful when you are on a Win box, but if you are trying to build infra from Linux/macOS you are struggling.
Here is a big list of powershell crap I have starred recently on Github:
- https://github.com/dsccommunity/ActiveDirectoryDsc (linked above)
- https://github.com/rmbolger/Posh-ACME
- https://github.com/DrEmpiricism/Optimize-Offline (not relevant to cross platform)
- https://github.com/W4RH4WK/Debloat-Windows-10 (not relevant to cross platform)
For example when I wanted to create and keep btrfs snapshot with exponential decay on their frequency, that would be quite tedious to write in Bash (I think, at least).
I used to like that I can run the same thing on Windows and Linux, but I stopped using Windows and got used to programs that would have to installed on Windows, so it's no longer an advantage to me. But in theory, it's still IMHO easier to run PowerShell script on Linux than it's to run Bash scripts on Windows.
I have not seen the nushell, thanks for posting that! From PowerShell I'd expect more online material and more stability.
It also has quite a bit of disadvantages: * Sometimes it's called `powershell` and sometimes `pwsh`, breaking shebangs * Startup is sloow. May be issue for some scripts that run often. * Linux people sometimes look at me very strangely :D * Installation size is significant if you count .NET into that. So not a good fit for setting up docker containers :/
(btw, it works on Linux for quite some time already)
This probably isn't something kbd would run into; the command is always `pwsh` on macOS/Linux.
Windows users get `powershell` (Powershell 5) and `pwsh` (Powershell Core 6 and Powershell 7) for backwards compatibility reasons. It's another `python` vs `python3` situation.
Since there are certain tasks that are more suitable with regular shell, I have Ctrl-Alt-P assigned to launch pwsh, and Ctrl-Alt-T assigned to zsh under Linux.
cross-platform, yeah, but I have big doubts about real niche & competition over C# stack. Why should people use this on Linux or mac?
Other scripts include synchronization of credentials from CyberArk Vault to Keepass, a start-up script which opens my common used applications and VPN (Outlook, Firefox, Visual Studio, OneNote, etc).
I also use it daily during software development if I need to manipulate or transform data I need during development.
My experience as a regular bash user and very occasional PowerShell one has been that I can write a script much more quickly using bash, but it has a better chance of getting things right first time using PowerShell. Generally this is because of simple things like the fact that arguments are passed in proper data structures rather than as quoted strings.
So I like PowerShell, it's effective and pragmatic and I think it's potentially good for scripts you want to put in production or redistribute. There are just a few problems -
* As an occasional user I find it all a little hard to keep track of, with liberal use of aliases and abbreviations (obviously intended to simplify things, but they mean reading examples is more complicated) and a less regular syntax around things like piping
* I believe that pipelines will (sometimes? often? always?) pass an in-memory structure rather than streaming - this can make it a lot less scalable (would appreciate correction on this but I do recall running out of memory on things I wouldn't have had a problem with in a Unix shell)
* The fact that it isn't "available by default" does matter, really - after all this is one of the biggest reasons one writes a shell script in the first place, rather than using some other language
Now that I’m on Linux and doing open source stuff, I’d never consider using PS.
- On Linux you have to learn bash anyway, because in the normal course of work you run across bash scripts everywhere.
- Everything on Linux is designed around the Unix philosophy and Unix tools, so PowerShell will feel out of place, and it'll be harder to find examples online. Also, Linux stuff is all configured via text files anyway, so PowerShell's object model is much less enticing.
- The shell's programming environment isn't that important because your scripts shouldn't be that long -- beyond 100 lines or so, you'd be way more productive using an actual programming language like Python instead.
I used PowerShell on Windows for 4-5 years professionally and it was great (finally ditching command.com was a revelation). Now, I've been using Linux, bash and stuff for about 3 years, and it's great. I guess I prefer the Linux environment because it feels tighter and faster.
I find many things to be easier than CMD/bash such as looping or chaining commands. I'd imagine nushell has similar benefits though.
Microsoft products such as Azure and AD are easily administered as well.
You've probably seem the widely circulated terminal colour test scripts written for Unices and Linux-based operating systems, such as 256colors.pl written in Perl and distributed with XTerm. This is a PowerShell approach. I wrote it to test what Windows Terminal could do.
It exemplifies several things.
It exemplifies the rapid prototyping nature of PowerShell. Development of this script went through several (unpublished) iterations, much of which was tested interactively. Doing that with Edit-Compile-Debug in, say, C would have taken longer.
It exemplifies that PowerShell is not limited to either TUI or GUI. The script both writes stuff to a Windows console and displays a GUI window with buttons.
It exemplifies the runtime library that one gets with PowerShell; here using Forms classes, the String class (including .NET string formatting), and of course the Console class. One gets the .NET (Core) Framework, basically, with which (on Windows) one can do things as varied as rewrite XML files, execute SQL, and (using its .NET API) enqueue builds on a TFS server.
In a very trivial way, it even exemplifies script blocks as lambdas (in the {Click} blocks being passed to the event handler registrations).
There's a whole lot more that it does not exemplify of course; including stuff like the -f and -is operators, hashes and arrays, PSCustomObjects, the object pipeline, ForEach-Object and Where-Object, nullable variables, and the extra standard streams.
And it really only tangentially, with the test at the top, illustrates how PowerShell is akin to TCL, LUA, et al., in that it can be (and is) embedded with different front-ends. In this case, the test ensures that the script isn't accidentally run in PowerShell ISE, which isn't a useful place to run the script, but more importantly which handles its console I/O really slowly to the point that it's actually difficult to interact with the UI. (I didn't employ a similar check for Visual Studio, whose embedded PowerShell has a console UI that is zero rows high.)
Meticulous. And clicking the headers link to comparisons at the tag level: https://github.com/PowerShell/PowerShell/compare/v7.0.0-prev...
And the hover link to the left of headers link perfectly to the section: https://github.com/PowerShell/PowerShell/blob/master/CHANGEL...
Sections: Breaking Changes, Engine Updates and Fixes, General Cmdlet Updates and Fixes, Code Cleanup, Tools, Tests, Build and Packaging Improvements, Documentation and Help Content
That's better than what I see in node and python projects.
So much thought and caring. Let's try it:
> brew cask install powershell
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/cask and caskroom/cask).
==> Updated Casks
caskroom/cask/microsoft-edge homebrew/cask/microsoft-edge
==> Downloading ...
powershell was successfully installed!
~ 23s
> pwsh
PowerShell 7.0.0
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/powershell
Type 'help' to get help.
PS /Users/tony>
Edit: You can open vim from it. Somehow, it's even detecting my tmuxp (which is in ~/.local/bin). I'm guessing it inherits PATH's from the parent shell?
On Linux, for example, you'll want to add something like this to your initialization / startup files:
export POWERSHELL_TELEMETRY_OPTOUT=1
But man,powershell is lightyears ahead of any *nix alternative. In particular, JEA for security and invoke-command (imagine running a block of code in parallel on multiple machines and get results locally) and other common cmdlets like import-csv where on something like bash you do have the capacity to do write a function that does these things but powershell provides these using a consistent interface,much like stdlibs do in application programming languages. After using powershell,using bash felt like trying to use C without it's stdlib. I think it's just windows' way of making up for nor having the equivalent of GNU userland tools like awk,sed and grep.
is incredible useful with dynamics 365
It's been a CLR front-end for forever. All the way back to PS2.0 you could (if you wish) define and execute an entire WPF GUI in Powershell (see https://poshgui.com/).
And for what ends? Seemingly to make more Microsoft technologies and APIs available on non-Windows platforms.
I genuinely like this part of the “new” Microsoft.
The last step would be creating Microsoft Linux for Developers when enough market penetration has been achieved, and making sure their tooling is hard to maintain in other distributions.
In my paranoid scenario, a happy ending (for Microsoft) would be: the release of its own Linux that "just works" with the mixed tooling, and young developers considering pure Linux just for small projects.
Found Bill Gates's account.
Microsoft has their own selfish reasons for wanting people to use powershell, while at the same time MS open sourcing powershell and providing it as a cross-platform tool people can use on their platform of choice benefits the open-source community?
Do you honestly think the open source projects from the likes of Apple, Google, Amazon, Twitter or Facebook is based on their good wishes and interests for “the open source community” (whatever that may be)? Really?
Or the good old day's when Ultrix ran like a racehorse on 4MB of ram (it did BTW!).
We don't do our credibility any favor when we live in the past and don't update our worldview based upon current facts.
Jeffrey Snover [MSFT]
So forgive me if I'm cynical of your company's current PR efforts.
It's also a nicer scripting language since it's table-based rather than string-based like Bash et al.
They want PowerShell to be the standard shell for managing Azure and Office 365.
They have Azure customers that aren't Windows users, so they have to cater for them. That's it.
Mind you, there's nothing wrong with this, it makes perfect business sense!
You are right that there is self interest in that (as Satya likes to say - it is hard to be successful if your customers aren't succeeding) but the PowerShell team has NEVER been confused about what the high order bit is.
Without going down the rabbit hole, I'll just point to the fact that our launch partners for PS Core were: - AWS - GCE - VMWARE
Jeffrey Snover [MSFT]
Generally the impression I have is that PowerShell development effort after v5.1 was 100% cloud-focused, and all Windows-native development stopped dead in the water. All videos and examples of PS6+ I saw were about cloud automation and Linux support.
If you would like to dispel my misconception, answer me this: Why has the PowerShell team not fixed any of the long-standing bugs in the Windows Server modules?
For example:
Get-ADUser 'nonexistent' -ErrorAction:SilentlyContinue
While we're here, how about the fun fact that "Set-Mailbox" doesn't have -WhatIf support, because who needs safety, anyway!? Or how if the very same command fails to find the specified mailbox it helpfully applies the change to the first 1000 users in your organisation instead. Clearly I wanted everyone to have the same surname with no rollback other than a full D/R restore. Fun times.
Nothing stops the PowerShell team from validating module behaviour against a set of standards and best-practices. Just because a module was authored elsewhere in Microsoft doesn't mean that you can't create issue tickets to get everything up to a baseline level.
I don't mean write their code for them. But it would be huge step up in perceived end-user quality of PowerShell in general if simply all Microsoft modules correctly supported -ErrorAction and -WhatIf. Similarly, support for PowerShell Core should have been fixed for all major modules long ago.
Microsoft created PowerShell and Microsoft created the Windows Server modules. From our perspective on the outside there is only Microsoft. We don't care about your internal politics. We do care about 1K mailboxes being irreversibly damaged.
Our perception is that third-party ISVs do a better job at writing PowerShell modules than Microsoft. Half the time I spend teaching PowerShell to customers is listing the many, many ways Microsoft violates their own rules and all the fiddly little workarounds required.
Meanwhile I just tested Pwsh 7 to see how well it works, and my first experience is that Connect-AzureAd fails because it uses the non-core SHA256Cng class instead of SHA256, so it can't connect unless I use a "preview" version from outside the PowerShell gallery. Nobody in their right mind would use preview code from a non-standard source to manage thousands of accounts in production. See: https://github.com/PowerShell/PowerShell/issues/10473#issuec...
I can't do "Microsoft things" with the "Microsoft shell", which renders Pwsh 7 useless to me and my customers. As far as I'm concerned, Pwsh 6, 6.1, 7, and most like 7.1 exist only to enable Linux and Mac users to automate Azure Resource Manager. Outside of that, most "Microsoft" things do not seem to work...
It's not difficult to make custom keybindings once you figure this out, but many people's first encounter with PowerShell is going to be missing some critical UX features. Not a great situation.
https://github.com/PowerShell/PSReadLine/issues/639 https://github.com/microsoft/terminal/issues/879
Talking about new changes in PowerShell 7.0 etc.
It looks like Powershell 7 still can't run some 5.1 scripts. Here's a compatibility table: https://docs.microsoft.com/en-us/powershell/scripting/whats-...
It's unlikely to ever reach even generally acceptable levels of compatibility with the built-in version.
Not everything is servers and containers.
The most used shell in *nix land is bash, but bash is significantly bigger than POSIX. This in practice means that many shell scripts are more bash-compliant than POSIX compliant.
It is part of the reason why it was good news when ubuntu/debian decided to transition to dash.
Having a Linux box with Alacritty and fish at home, makes it even more frustrating to start in on Windows and wait seconds to type.
And unfortunately, PS 7.0 is not a lot faster, still noticeable lag in startup.
The good part is .net integration, being able to use standard .net classes in scripts can be really helpful.
(Of course, Microsoft being Microsoft one still needed to install MS Office on the server to use Azure Information Protection on a pdf or even a txt file...)
Some-Command -Param1 -FileData .\foobar.xml
In bash you would just do:
somecommand < foobar.xml
[Byte[]]$Data = Get-Content -Path ".\foobar.xml" -Encoding Byte -ReadCount 0
Some-Command -Param1 -FileData $DataI like the pipeline parallelization feature, I wish more languages offered simple semantics like this to just parallelize some basic tasks.
There are some nice things compared to bash, like tab completion on program arguments. However it is somewhat slow.
What surprises me is that somethings are just awkward & cumbersome, like excluding multiple folders when doing Get-ChildItem.
https://stackoverflow.com/questions/15294836/how-can-i-exclu...
Or escaping arguments with correct quoting. Sometimes I can't get it to work, like searching for strings with weird characters, especially if I need to combine it with git grep.
Bash has that as well.
This thread is full of praise for PowerShell, but every time I've tried to use it, I've become annoyed with it. For example, to get the size of a folder in Bash, I'd type `du -sh <folder>`. In PowerShell it's some absurd code spaghetti that someone put in a Github repo [1]. No matter what I try to do in PS, I find the syntax ridiculously verbose. Maybe I just don't get it, whatever it is. \shrug\
Edit: (I only use it to orchestrate and combine other build systems though)
If you /did/ need to do it without `du` then it would be something like:
`dir <folder> -Recurse | measure -Property Length -Sum`
which is easier to remember than whatever the equivalent bash would be, imo.
Maybe not in a technical sense, but I've never encountered Bash without GNU coreutils (or busybox). I'm just comparing how I would solve a problem in a typical *nix environment, compared to a Windows environment.
> Current version: 7.0.0
EDIT: "This is not a fork. This is a repository of scripts to automatically build Microsoft's vscode repository into freely-licensed binaries with a community-driven default configuration."
Let me take the opportunity to say:
1) YOU ARE NOT OUR PRODUCT! 2) Our goal is to use telemetry to help us make better decisions about what will help our customers (as with with projects, only a subset of users are active in our community feedback process) 3) We are super open about the telemetry (including going through the PowerShell community review process) and publish all the data. More details here: https://devblogs.microsoft.com/powershell/new-telemetry-in-p...
Here is all the telemetry: https://aka.ms/psgithubbi
Jeffrey Snover [MSFT]
I fully appreciate the importance of telemetry, crash reports etc. for product owners and teams, and am not under the impression that it is currently being abused by msft.
However, as telemetry is a very general functionality and by their nature both company policies and software products are subject to frequent changes and given the many example of abuse by some companies quite comparable to msft in terms of their scope of impact and business incentives I don't think its usefulness overrides the principal concerns regarding the practice of including it enabled by default with distributed products even when disclosed.
Anything that does not require an explicit user action to enable telemetry imo falls short of the desired ethical standard of respect for user agency that should exist in an ecosystem that wishes to foster trust between vendors and users and this goes double for open-source projects.
Personally, I disagree. I think that telemetry should be clearly disclosed (as any kind of 'phone home' functionality), so as to give user full knowledge of what will run on their machine.
In this sense something negative about telemetry is that it is not uncommon to find it turned on by default after an update (I have no idea whether this applies to Microsoft), or when in situation like the recent gitlab blunder they decided to have third-party scripts for telemetry.
For anything else active-by-default telemetry is in the same category as adding half a dozen random dot-files in your home directory (which often is not configurable).
> ... this goes double for open-source projects.
Again I disagree, with free-software you have the right to run a telemetry free version of the product and with open-source you have the ability to actually inspect what the telemetry is doing.
The place where telemetry is sort of shady is the gray area that is neither free/open software not enterprise agreements with legally binding reasonable contracts; which includes for example Windows 10.
The free software vs. open-source distinction is quite subjective but irrelevant here - Powershell source code is released under the MIT license which allows anyone to produce a modified telemetry-free build but sensibly does not obligate the authors to provide one themselves, hence my original comment.
A trustworthy way to do this would have been to have the user presented with a prompt upon first interactive run explaining them the importance of the telemetry to msft with a link to relevant documentation and privacy policy and a Y/N selection, anytime the collection logic changes or a new datum is added the consent needs to be renewed, and if it turns out that under those conditions most users choose not to enable it than it will probably be the single most actionable user input msft receives from/about its telemetry practices.
You might say it’s more a tool that shines in the cases where you’d already give up on bash and use python or something else instead, because you need some libraries, some structured error handling etc.