Literally every windows admin uses it. It's the official commandline interface for microsoft software.

Every piece of microsoft software must provide a ps interface. It's an engineering directive.

It is strange to claim no one really uses powershell. It is widely used in the Windows world.

The main complaint I see about powershell is that it isn't bash. The object pipeline in powershell can be so much more powerful than parsing text between commands. After all, that's why we have data types instead of storing everything in strings.

It's not widely used in the Windows world from what I can see.

Walk into any office and ask an IT guy to run "ipconfig". They'll open up cmd.exe without even thinking about it.

I read a lot of programming tutorials. Nobody ever reference PowerShell in them. They always instruct people to open cmd.

Do you have any evidence to the contrary?

Someone else posted the evidence below.

In an attempt to understand and empathize with people who do not share my opinions, I looked back through some of your post history and you said this 5 days ago:

"It's never been clear to me why anyone would want to use a completely opaque and undiscoverable interface such as a commandline over a nice GUI for anything. You didn't have to read anything or search around in order to change all of those settings in the GUI."

Maybe it's possible you're not familiar with people who use powershell because you tend to stick to the GUI?

That's a good point - almost everywhere I go as a consultant...their IT people use the GUI to manage things and not PowerShell.

Most places that I've seen automate things with a .NET program whether it's a service, a console app run via Task Scheduler, an SSIS package and in a few cases - a desktop app.

EDIT: I'm a programmer and not a sysadmin except for on my own network where I do prefer "the easy way" as opposed to the way where you have to do rote memorization to perform simple tasks. If I automate anything, it's also done with .NET or Node.js because I like the tools better and my stuff runs everywhere without performing any ceremonies. I do visit a lot of client sites though and I work with client sysadmins regularly. I'm on the East coast and I work in the NY/NJ/PA area. Also the reason I like bash better is because if I have to memorize anything (and I do, for Linux work)...I'd rather have it be something terse.

You seem to be missing the fact that powershell is just designed better. Take powershell vs bash. Bash operates primarily on strings. In powershell everything that is interacted with is an object. This wont really effect you in day to day interactions, but it is incredibly useful when you decide that you want to automate something. This combined with the fact that powershell is built on the .net framework means that there is a simple way to extend it from C#. You should give it an honest try sometime. Its not really that much more verbose in everyday practice and it has lots of tools around it that make life simpler.

https://www.powershellgallery.com/stats - 100k+ downloads of DSC resources in the last 6 weeks.

https://github.com/search?l=PowerShell&q=powershell&type=Rep... - 7,600 GitHub repositories (compared to 20,000 'shell' and 19,000 'perl')

40k questions on StackOverflow tagged PowerShell, vs. 54k tagged 'Perl', 50k tagged 'shell', 76k tagged 'bash'.

20k /r/powershell subscribers, 10k /r/bash subscribers on Reddit.

> Walk into any office and ask an IT guy to run "ipconfig". They'll open up cmd.exe without even thinking about it.

Absolutely because of twenty years of muscle memory.

But once Powershell is the default and they learn about the wonderful "gip" alias, they'll be hooked. "gip" in case people don't know is an alias for Get-NetIpConfiguration which is a more powerful version of IPConfig.

PS - "gip -all" is useful. "gip -all -d" for more detailed results.

Why would I run PowerShell for ipconfig? Just do the easiest thing.

Running a multi line script that does nearly anything important? Well yes I am definitely going to use PowerShell.

For simple tasks such as running a command, sure. But if that admin needs to do anything more complex, such as parsing the output of ipconfig, they're most likely going to use powershell.

Every windows admin uses it but all the admins I know don't particularly like it or fully understand it. They do like what they can do with it, that they can script almost everything, and it's far better than cmd.exe but honestly the syntax and semantics are pretty baffling.

There's a lot of cargo-cult copy and pasting in the powershell community.

That's all correct and it is the right way to do things (especially from Microsoft's perspective). However, the main goal of Powershell seems to be providing a scripting language that can automate Windows internals and not a shell in which you live in. Powershell is just a nice REPL, not so much a shell as you might be used from Bash.

We have had Powershell for 10 years now. Has it taken off in a big way? No. The admins you mentioned use it because simple automation is the one thing GUIs cannot provide and MS had to face this after over a decade of denial.

Do people get out Powershell instead of Python to do cool new projects that are unrelated to devops or admin work? Some maybe. But the real music plays somewhere else. And some of the reasons for that have been mentioned by the GP.

I wouldn't take out bash or zsh or whatever else to do a project either. But I do use it when I want to run a bunch of cmdline tools.

Right tool for the job and all...

I compared Powershell to Python regarding projects, not Bash.

It could have been 1. a shell 2. an automation tool 3. a scripting language, yet it fails at 1., is ignored regarding 3., and only succeds at 2.

Powershell is designed for devops and admin work. I wouldn't use it for anything else.

> Literally every windows admin uses it.

And how much people with those be? Probably a lot less that software developers in general, and non-windows admins.

"admin"

This would be a good move if it was on Windows Server.

I've never quite understood the concern about needing to Set-ExecutionPolicy before running scripts.

In Unix, you have to chmod a+x a file before running it. And you have to do it for every script you want to run.

So to run 1 cmdlet to enable all scripts seems a bargain. (Honestly I could be missing something and I probably am because you are not the first person to mention it. I just can't connect the dots.)

Jeffrey Snover [MSFT]

My problem with the Execution Policy is that it's useless in practice since it doesn't actually prevent anything (so it annoys me every time). What was the motivation for adding it since it's not a real security feature? If it actually prevented executing stuff full stop it would be cool. The signed script concept is cool... I wish I could do that with Python.

Was it just to prevent accidental script execution?

That is correct (prevent accidental script execution).

It is ABSOLUTELY NOT a security mechanism. That is why we we support this:

Set-ExecutionPolicy -ExecutionPolicy Bypass

I wanted to make it:

Set-ExecutionPolicy -ExecutionPolicy DoAnythingBecauseTExecutionPolicyIsNOTASecurityFeature

But the team didn't like that. (I should have overruled them on that one :-) ).

Jeffrey Snover [MSFT]

I think the problem is that when you chmod a file it stays chmoded. With the Set-ExecutionPolicy I find that I have to do it every time I start a shell. I also run a lot of headless scripts (AWS cloud-init, services, etc.) and it's always a pain resetting everything every time. With Unix, I know that a script is executable or not, with PS I don't.

Also, I might not want every script to be executable. With Unix I can choose which ones are executable and by whom. With PS it's all or nothing. :/

Yikes! - you shouldn't have to do Set-ExecutionPolicy every time you start a shell. Something is definitely wrong there.

Try doing a: Get-ExecutionPolicy -List to see what is setting it.

Then use -SCOPE on Set-ExecutionPolicy.

BTW - I hear you on the "only chmod the scripts you want" - that is a nice benefit of the Unix model.

Jeffrey Snover [MSFT]

I totally get where you are coming from. When having to do work on Windows, I used to go out of my way to avoid PowerShell.

I finally gave it a solid chance one day and I've found that it can be surprisingly nice and powerful to work with.

You can globally disable policy enforcement. Maybe not the most "secure", but it's not something I wish to bother with. There is also a really nice package management system for PowerShell modules with things like git integration and etc.

You can check out my shell configuration here: https://gitlab.com/lholden/WindowsPowerShell

Java developer here, multi-OS fan. I'm using both PowerShell and bash from Windows Ubuntu subsystem. I prefer PS on Windows because I do like its object pipeline, but have to use bash for some cross-platform automation.

Powershell users don't age gracefully, that's for sure. You'll learn some arcane long-winded way of doing something in v3 and it will be relaced with something far better. Unfortunately, you'll still have to know the old way.

As for longwinded, I hate using ACL in Powershell. Let's say you have to reestablish FullControl on a bunch of files as an Administrator and you don't have Write access. It's so convoluted and it can even fail silently. So much easier to just use icacls in a single line.

I'm going to address each bullet:

- Set-ExecutionPolicy can be set with a single click from the "For Developer Settings." Just scroll down and hit Apply three times and your machine has sane developer defaults (inc. ExecutionPolicy).

- The verbosity means that you can "guess" PS commands. Each PS command is a set layout with an action word (e.g. Add, Clear, Get, Write, etc) and then target (e.g. Set-Alias, Set-Date, Set-Service, etc).

- A ton of people use PS. In particular SysAdmins are moving from VBS/Bat to PS in droves. No clue what communities you hang out with where nobody uses it?

- It is definitely still a work in progress. But most of the core parts of the language hasn't changed much, if you wrote a PS file three years ago it likely still works today. All they've done is add new cmdlets, new libraries, and new functionality which doesn't hurt backwards compatibility.

> If you wrote a PS file three years ago it likely still works today.

That's a really low bar.

Isn't Windows supposed to have a legendary commitment to backwards compatibility? 3 years of backwards compatibility would be nice for a bleeding-edge development environment like node.js that you can tear down and replace whenever you want, but not for your operating system shell.

Guess? With naming conventions like "Get-ChildItem"?

Major functionality, probably the worst name you could come up with.

A single anecdote doesn't discount a trend.

Being able to predict a PS cmdlet based on patterns works. I know, because I use it daily.