Which is fine when you're starting out, but infinitely frustrating after you have an idea of what you're doing.

A recent example, looking for errors in windows logs:

    Get-Childitem "C:\Windows\" -recurse -Include *.log ` | Select-String "Error" -ErrorAction SilentlyContinue ` | Group-Object filename | Sort-Object count -descending

Closest *NIX analogue I can think of would be

    grep -r Error /var/log/ | sort

English is an arguably fine speaking language but an awful programming one.

I love what Powershell can do, but gods do I hate typing it.

Those two lines do different things. They're not analogous.

The equivalent to the UNIX line above in Powershell is:

      ls "C:\app\*.log" -R  | sls "Error" | sort       

You cannot just tack on a bunch of extra requirements for Powershell (grouping, sorting by certain things and in a certain order) and then not include them in the UNIX example, that's disingenuous/misleading.

The only big difference between PS and UNIX in an actual analogous example is that the PS version of grep gets files fed in one by one and processes them, whereas UNIX's grep processes files itself.

PS - The above Powershell code may not work in 2.0 (2009). You'll need 3.0 (2012) or higher.

Hence "I can think of". That was copypasta from an internal wiki. I don't appreciate being accused of "disingenousness" from an off the cuff example.

By the way, your example is precisely 12 characters longer than mine and still multiple times shorter than the equivalent PS, so if your goal was to somehow disprove PowerShell's annoying verboseness rather than snark at me, you failed.

> I don't appreciate being accused of "disingenousness" from an off the cuff example.

Then check your examples before you post them to make a specific point. It is a point of fact that calling those two things "analogous" is incorrect, and your offense doesn't change that fact.

You also specifically said "I can think of" implying that you created the examples rather than that you got them from an "internal wiki." The fact that you said you thought of the UNIX example gives me solid ground to describe the created example as disingenuous.

I cannot help it if you're being misleading about how your got your examples.

> By the way, your example is precisely 12 characters longer than mine and still multiple times shorter than the equivalent PS, so if your goal was to somehow disprove PowerShell's annoying verboseness rather than snark at me, you failed.

My point was your examples were poorly constructed and misleading. I proved my point I believe. The difference between my accurate example of PS and your inaccurate example are night and day.

I'll leave it up to the reader to decide if PS's syntax is more to their liking. I just think they should start off with accurate information so they can form an accurate determination themselves.

In other words I won't get drawn into comparing my PS example with your UNIX example. I just want both examples to be truly analogous of one another.

>By the way, your example is precisely 12 characters longer than mine and still multiple times shorter than the equivalent PS

I think you didn't realize, but what Someone1234 has there is the equivalent PS, not UNIX shell.

    (iwr "http://Slashdot.org").Links | select href

Nearest Unix equivalent please.

    lynx -dump -listonly http://Slashdot.org

Not exactly, but close. Needs more work if you want to pipe it further.

What does that even do? Sorry, I’m not familiar with Windows, but would love to provide a unix equivalent.

Fetches http://Slashdot.org (`iwr ...`), parses it as an HTML page and extracts all the anchor tags (`.Links`), and selects the href of each anchor tag (`select href`). Since this is the end of the command, the hrefs are returned and printed as an array of strings (so one href on each line).

Including the href="" bit?

Just the values. The same things you'd get by accessing the href property in JavaScript.

Well, with just grep and curl, it'd be something like:

    curl http://slashdot.org/ | grep -o "href=[\"'][^\"']*" | sed -e "s/href=\"//"

But presumably this is being discounted due to the lack of HTML parsing, so not the same as the Powershell example. Then one somewhat ugly method would be using the html xml utilities provided by the W3C and available on most package managers:

    curl http://slashdot.org/ | hxpipe 2> /dev/null | grep Ahref | sed -e "s/Ahref CDATA //"

Obviously not as pretty, but it does do a nice job of going through the HTML tree, and doesn't rely on nicely formed XML that /usr/bin/xpath would.

Yes, a naive grep will pick up variables named href in JS, the text content of a div that contains "href", an href attribute on a non-anchor element, etc. so a utility that specifically parses HTML is necessary, but not sufficient.

I'm not sure how robust your hxpipe example is against those.

It's a shell script. If you're architecturing more than that in your shell script, I would suggest that you shouldn't be doing this in a terminal in the first place. And if you're just trying to click links for a quick shell script, why not just do it via wget in the first place, rather than have this intermediate list of strings?

But since you asked, hxpipe assumes that href on a non anchor tag is an error and should be represented as an Ahref... which isn't too bad an assumption to make, tbf. The other situations is dealt with (text content, javascript).

I'd agree it's a bit more to type out, but it does seem to make more sense from a readability perspective. And for those of us who didn't grow up with the UNIX shell to understand the reasons why things were kept so short, it's a bit easier to digest. (I do appreciate why bash is so short and succulent. =)

But really, taking the above into consideration, the might in powershell comes not from the terms used, in my opinion, but how it works on things. With grep for example, you're parsing a file. If say, you wanted to filter on that more, you'd be using awk to pick out parts of the text.

In Powershell, everything's an object. Everything's already an object, you don't need to pick the file apart to isolate the date, you just filter on the date object. It's got a data type.

That makes it really powerful, in my opinion.

(Example largely pulled from "Windows Powershell in Action". I really like this book, as it goes into detail to describe /why/ things are they way they are in PowerShell, because he wrote it. =) https://www.manning.com/books/windows-powershell-in-action-s...

> but it does seem to make more sense from a readability perspective

Not really, as everything is given an unreadable alias anyway, and many are given multiple aliases: Copy-Item -> copy,cp,cpi. So there are just more names to learn.

You don't have to use the aliases though, and they don't tab complete (only the full name does)

Personally, I never use them. I saw them more as a help for people coming over from bash.

You do have to use them unless you work alone. I regularly see PS1 files that use the various aliases, as well as the fully-named commands.

Lots of powershell cmdlets have aliases too. They are less discoverable than the verb-noun names, but for cmdlets I use often they are great. Get-ChildItem is aliased to gci, ls, and dir.

Try links and environment variables to substitute long commands and flags, respectively. Fine, it’s not there by default, but as a power user you have the ability to adapt it to your needs. (That would also be a cool fix to release on GitHub for others like you to use as well. Yay hackability!)

Right. When I found out that this was supposed to be the alternative, I almost lost it.

For the thing to become usable, you have to do personal configuration, meaning your system will be unusable to anyone else and theirs will be unusable to you.

Back to the drawing board...

I'd also wager Select-String is an order of magnitude slower than grep or ag.

You'd be wrong (at least for grep) http://www.jwgoerlich.us/blogengine/post/2013/01/21/Grep-ver...

Except, GNU grep is even faster than Select-String, if you run it on a better filesystem.

NTFS is only a turd on lots of small writes. It really flies on reads.

Unless it is fragmented heavily, which often tends to happen.

Pretty much a non issue since 2012. It defrags itself.

> Cumbersome or you just aren't familiar with it yet?

Cumbersome. To create my own cmdlet that does the cool stuff Powershell can do (as far as piping) my choices are a terrible language like ps1 or .NET.

On Unix I can use pretty much whatever I want because the shell isn't tied to a specific runtime.

On Unix you can do pretty much whatever you want as long as "whatever I want" can be represented by a string of text. In PS you get to work with objects. PS is more like a Python shell than bash.

If you want, your PS commandlets can return strings as well, so it's not like every part of your pipeline has to be in PS either.

Although you can have succinctness, most commands have shortcuts for them.

Get-Content = gc or cat

for example