I was forced to use Powershell for a project so after years of ignoring I finally learned it. It’s actually not that bad and I have even done some stuff on my Mac with Powershell core.
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.
> Typescript and C# have demonstrated that MS can design good languages
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.
Visual Basic pre-dates Delphi. Remember VB6 was the 6th iteration of Visual Basic and VB hadn't really changed that much since at least Visual Basic 3 (which was the earliest version I used).
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.
I love what Jobs did and I like Apple way better when he was there but Jobs didn't do it all by himself, he decided. So, I think that's different from 1 genius software architect building it directly.
I used to spend a lot of time writing Powershell (b/w versions 3-5). Absolutely loved the language, but my love for it fell off after learning more commonly-used scripting languages like Python and Ruby.
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.
You expect powershell to be like C#,typescript or python when it is more akin to bash. It is a scripting language specifically designed for a command interpreter.
I would agree that Powershell has less quirks than bash which sometimes feels like one big quirk. But I think they could do much better. During my project we ran into a ton of issues around scope, return values from functions and other stuff that were really hard to deal with. You don’t see that with small scripts but our project has thousands of lines and becoming hard to manage. Now some smartass will say that Powershell is not designed for a project of that size but the cmdlets almost force you to use it for certain types of tasks. It would be pretty difficult to rewrite that code in another language.
Once you realize that you need classes to return values and functions don't return values I (admittedly not an expert) don't see anything more complex beyond that.
This thing itself seems like a quirk but again I'm not an expert so don't know how this was designed.
I wrote quite a lot of PowerShell code. I really like the language, except when I don't. And return and outputs in general are among the most infuriating points.
> 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.
Function return values is among the worst ideas the PowerShell designers dreamed up. A function will (more or less) return anything output to the terminal. This is a particularly bizarre decision considering how difficult it can be to get many Windows commands to be completely silent. Error handling, redirecting output, etc. all fail in many circumstances. It was completely aggravating. It has been a few years, so hopefully that's changed.
I don’t remember the exact details but for example loading classes that reference each other was hard unless they were all in the same file. I ended up writing a preload step that would combine all library files into one big file and execute that. In general I found it hard to write reusable code once that code started referencing each other. Maybe there are ways around that but it seems kind of stupid to create a new way of achieving what other languages have already solved decades ago.
If cmdlets were easier to use i would probably have used a proper language like csscript or C# instead of Powershell.
If you have modules in your module path that don't declare their exports in the manifest, PowerShell has to inspect everything to find all the cmds. This is often what is going on when you have terrible startup times.
Look who's here! Everybody Jeff is the chief architect of Powershell and someone pretty high up Microsoft right now.
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 ) ...
Step by step we've been doing more and more focused on Linux users. If you take a look at our telemetry - it is clear something is working because Linux usage is through the roof!!!
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.
PowerShell is a shell - a program that takes input, does work, and returns output.
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.
The start time is a major disadvantage behind Powershell. It takes 3 seconds to load even if you disable profiles completely versus <1 second for Python, Ruby or Bash.
Process creation on Windows has always been significantly slower than Unix. That is why PowerShell is skewed towards "built-ins" vs launched applications. The ramification of that is slower startup times.
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.
This is an idea we've discussed, but not something we're investing in right now. It could also solve the sudo/elevation problem for cmdlets. However a privileged service would also bring more security concerns.
Hey Steve you're doing a great job with PS! Thank you for all the hard work you and your guys are doing. You are also exceptionally responsive on GitHub.
I'm interested now that PowerShell is cross platform. For someone reasonably fluent in bash/zsh (and Python, etc.) already, could someone give examples of where they might use PowerShell?
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.
I like to use PowerShell for scripts (sometimes), while I use fish as a interactive shell. I'm a SW developer familiar with .NET, and it's reasonably easy to call any .NET functions from PowerShell while it's also easy to call any external program (do pipes and all this unixy things). Mostly, my use cases are things other people would use Python rather than Bash. PowerShell is a compromise between the two, in my view.
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)
> Sometimes it's called `powershell` and sometimes `pwsh`
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.
> For someone reasonably fluent in bash/zsh (and Python, etc.) already, could someone give examples of where they might use PowerShell?
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
Besides devops, I also do sysops for the servers of my team. Backup scripts, scripts for monitoring (plugins for NSClient++) and various utility scripts are written in Powershell.
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.
I use pwsh as my main shell on both Windows and Linux. For me it's just more sane than bash with less pitfalls that I've experienced. And if there's something I can't do in pwsh, I have the full power of the .net CLR to do it for me.
I have been using pwsh on Linux fairly regularly, too. I got plenty of script and C# modules that I have been using to automate some tasks. (Data wrangling, scraping, and merging, etc.) that I want to use both on Windows and Linux.
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.
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.)
The only time I'm forced to use PowerShell is when dealing with edge cases involving MS products. In our case, we needed to refresh SQL Server Cube data within an Excel file and we didn't want to use iron Python, so we relied on PowerShell for doing the refresh work while Python controlled its process.
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.
Please no. They already compromise a lot on the design of UWP to support JavaScript. Also, JSX was supported for decades on Windows and I don’t think it got any adoption.
The syntax however should get a lifting, to result in something like C# but with less curly braces.
Active Scripting was the Powershell before Powershell. Not in a sense that it's a shell scripting language, but in a sense that it's what Windows admins used to wrote scripts more complicated than a batch file.
That thing supports VBScript and JScript out of the box. Most scripts are written in VBS in practice, though.
I find it fantastic for running scripts on multiple machines. The invoke-command cmdlet makes it very easy to do this if your computers are a domain or have the same username and password. Credentials can also be supplied but that's more cumbersome.
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.
Do the Office 365, Active Directory, etc modules actually run on Linux or MacOS now? Last time I tried Powershell on my Mac, it couldn't do any of that stuff, and I felt like it was pretty useless to run on anything other than Windows.
With all of their embracing of Linux these days, too bad MS didn't have the balls to integrate bash into Windows back then instead of coming up with something that only Windows users would be using.
I use PowerShell mostly for pulling data from Active Directory. Used to write little C# programs for this but PS has a nice AD module that covers most of the common tasks I need to perform.
The ecosystem of stuff is the first thing that comes to mind. Windows has never been an environment that was well suited for modern automation practices (infrastructure as code).
For instance, it's not straightforward to take a database or XLS document of users and transform that into an Active Directory implementation.
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:
I’d only consider PowerShell when working with tech that is best managed through it, so stuff from Microsoft. It was great for the couple years I used it full time, even built a test runner that used .NET TCP classes to automate stuff through a telnet connection.
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.
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>
I'm using Powershell, a C# application, on MacOS, in iTerm2. I'm fine with it. Also, the subsequent bootup of pwsh was faster than the first.
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?
Yes, pwsh inherits from parent. However, we've made improvements to use PS7 as a login shell. When used as a login shell, we exec sh on Linux and zsh on macOS to setup the environment, then exec pwsh to inherit.
Having to opt-out of telemetry in your shell is revolting. I wasn't even aware it was there. They really need better up-front warnings (or opt-in) for their OS and shell etc. Another nail in the coffin, horrible dark pattern.
Pretty exciting, someone showed me a while back how powershell 6 has a wget command. I look forward to simple things like this
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.
I hope that Microsoft has a long-term plan for Powershell. It started as a simple shell and has evolved into an almost full-fledged programming language.
It was (almost? I never played with PS1.0) always a "almost full-fledged programming language".
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/).
That's not quite right.
We have always focused on CUSTOMER success.
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
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?
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.
The PowerShell team doesn't own most of the modules that are shipped in Windows Server. Windows Server is a big project that takes many teams to work together to produce. In your specific example, the AD team owns that module. Set-Mailbox issues need to be sent to the Exchange team. I know you may not like that answer, but it's not feasible for a single team to own so many cmdlets that require different domain expertise.
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...
I feel like we're in the "extend" phase of embrace-extend-extinguish cycle.
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.
I think today embrace, extend and extinguish applies more to cloud providers like AWS. They take a lot of open source, wrap it into their own code and then lock people in. MS is one of the perpetrators but Amazon and Google are no better.
This is just speculation on my part, but the technology being adopted is likely Linux. First Microsoft declares its war on Linux over (Microsoft loves Linux), then the Windows tooling is extended into Linux so the lines blur, then WSL was made so you don't have to leave Windows to use Linux tooling.
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.
Thank God you realize this. Just yesterday I noticed that systemd uses azure pipelines for testing and somebody as wise as you told me that Microsoft is slowly adding windows Installer code to systemd and in a few years you may think you're installing linux but upon first boot systemd will actually install windows.
People too young to remember the anti-trust days will deny it, but there is no good reason to trust that this isn't Microsoft's long term plan. You'd be a fool to believe Microsoft has the best interests of the open source community at heart.
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?
Current facts: Microsoft shoves ads into the start menu and file explorer, collects a ton of telemetry, resets application associations during updates, and does its best to hide the ability to setup a local-only account during install in its pay-for operating system.
So forgive me if I'm cynical of your company's current PR efforts.
I was just trying to get a release candidate of PowerShell 7 working on macOS and Windows yesterday. It was a frustrating experience, because many essential keybindings are broken out of the box on macOS (Terminal.app, iTerm2) and Windows (using the new Windows Terminal). For example: ctrl-space is the usual shortcut to trigger menu completion, doesn't 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.
Ternary operators and better Get-Error output are very welcome additions, Ive been writing a few infrastructure testing tools in Pester that could possibly be consolidated.
They changed the default path outout of applets like get-childitem. Microsoft employees stated that this would break many older scripts, but it wasn't listed as a breaking change.
It's unlikely to ever reach even generally acceptable levels of compatibility with the built-in version.
There's no reason to bake tools like this into an OS or tie them to OS versions. Download the tools you need. If you need to "bake" them anywhere, bake them into your containers.
How many non-server machines do you find yourself regularly needing a shell on where downloading it isn't an option? Why does it need to be pre-installed?
On the other hand reliance on bash-specific features is a net negative for GNU/linux.
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.
The documentation notes that MSIX installers should be built (I didn't see any in the GitHub Releases, so maybe it is a coming soon thing), so I'm hoping that also means a possible option to install and update it from the Store. That would at least "feel" a little more baked-in to Windows than installing from a GitHub Release page.
I like PowerShell in general. But it's very slow. Both the startup time and the responsiveness. Especially when having something like posh-git enabled.
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.
I used Powershell a lot last year and it is really amazing to be able to script things like Azure Information Protection and use Azure Application Insights for logging..!
(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...)
Coming from a bash background, PowerShell is consistently annoying. Here's an example, passing an XML file to a cmdlet:
Some-Command -Param1 -FileData .\foobar.xml
Cannot process argument transformation on parameter 'FileData'. Cannot convert value ".\foo.xml" to type "System.Byte[]". Error: "Cannot convert value ".\foo.xml" to type "System.Byte". Error: "Input string was not in a correct format.""
In bash you would just do:
somecommand < foobar.xml
Instead you have to create an object and, do a conversion:
Interestingly, I saw that PowerShell 7.0 was the default level of documentation when I was browsing Microsoft docs yesterday and figured I must've missed the announcement.
I like the pipeline parallelization feature, I wish more languages offered simple semantics like this to just parallelize some basic tasks.
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.
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\
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.
This is my experience too, anything non-trivial quickly becomes an absolute mess, even the trivial things often have bad defaults. A few years ago I looked into using it as a build system for .net projects but ended up tearing my hair out on even the simplest things like removing directories or recursively copying html files: http://flukus.github.io/powershell-is-a-joke.html
There are enough examples of companies doing terrible stuff that concerns are entirely understandable.
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...
Thanks for taking the time to address this (And a great thanks for Powershell ! Which regardless of some reservations about its language is a great technology and a major leap forward in terms of soundness and productivity in the IT sphere)
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.
Given that PowerShell is Open Source, you can exactly see the telemetry code. Before we added the first bit of telemetry or when we needed to add more, we published RFCs for community feedback disclosing what we were collecting and why. https://github.com/PowerShell/PowerShell-RFC/blob/master/5-F... and https://github.com/PowerShell/PowerShell-RFC/blob/master/2-D.... We recognize that some users don't want to send any, which is why we made it simple to disable (completely!). However, opt-in telemetry also means we would receive very little making it not useful. Before any telemetry is added, we also go through an extensive privacy review to ensure no personally identifiable information is included (therefore all our telemetry is anonymous).
The average user cannot be assumed or expected to be following powershell blogs or to have gone through the community discussions or to have read the RFCs and definitely not to have individually reviewed the source code, they would just download and run powershell while not being aware that this functionality even exists and be dismayed once they learn about it. In this onboarding scenario the current form does not even satisfy good faith disclosure criteria much less can be said to constitute an informed consent.
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.
> 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
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.
Well at this point it is not even clearly disclosed, as I have just downloaded a release .tar.gz from github, unpacked it, ran it and saw no mention of telemetry or its opt-out options.
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.
Although it appears to be a binary-only download claiming to be free of telemetry and non-floss code, it does not share the fork itself, what am I missing here ?
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."
When you are doing things that operate on unstructured text and files you will probably get a more concise script with bash most of the time. As soon as you do anything beyond that with structured data or complex processing (e.g you fetch a Json from a web api, filter some properties in it with a regex, save the result as xml, send the xml to a program, parse the output using some complex logic,...) then the powershell is way more powerful.
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.
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.