While a great fan of PowerShell in theory, in practice it seems to be extremely cumbersome. Sort of the opposite of bash and other Unix shells, which suck in theory and are very useful/convenient/powerful in practice.
Cumbersome or you just aren't familiar with it yet?
The whole design of PS is meant to make it so you can "guess" the names of cmdlets you've never used before. Everything is Verb-Noun, Get-Service, New-Service, Restart-Service, Stop-Service, etc.
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.
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).
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:
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.
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.
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.
yeah, powershell is limited on the backward compatibility with dos. the few times i had to do anything on windows more than that one-off time, i end up installing a sshd (there are a few options) and use putty to localhost.
While a great fan of PowerShell in theory, in practice it seems to be extremely cumbersome. Sort of the opposite of bash and other Unix shells, which suck in theory and are very useful/convenient/powerful in practice.