8 ms·

I Like Powershell

55 points by BerislavLopac 4y ago

IYasha 4y ago
(linux user): isn't Powershell that new slow as hell command prompt based on some .NET? No, thanks. It's just terrible as everything made of .NET.
tpoacher 4y ago
Nice article, and this is obviously a very specific nitpick from a single point in the article, but ... > ls --full-time | cut -d' ' -f6,7 # WRONG > If two “fields” have different lengths, ls will add spaces to the name of the smaller one to make the two line up, which will break cut -d' '. And in fact you can’t solve this at all with ls, you have to write stat -c %w. Text streams don’t compose. I mean, ok, I get the point how he's saying Powershell has 'objects', but the example is super-contrived. All it takes to fix the offending 'padding spaces' is to remove them. ls --full-time | tr -s ' ' | cut -d' ' -f6-7 Moreover, that's not even "bash" you're comparing against, but 'coreutils'. If you really wanted to grab the output of 'ls' with pure bash then you'd probably go with something like this instead: ls --full-time | while read -r FIELD{1..8}; do echo "$FIELD6 $FIELD7"; done which isn't exactly complicated either. Otherwise, if the gripe is about the command you're using not being field based, then go ahead and use one that is, on data that supports it. This isn't exactly a language issue. Case in point, if 'stat' is the right command to get that "field" for that "object type", then there you go. Nagging that if you don't use the right tool for the job will leave you with having to work around things, is not exactly the environment's fault. Also, text streams absolutely do compose. It's just that the underlying type will always be a text stream. But composability is 100% the reason behind this in the first place.
PreInternet01 4y ago
Well, I don't, and I'm a Windows fanboy. So, why, exactly none of you ask: 1. The PowerShell separation of, what on *ix* systems is stdout and stderr, doesn't really work. Want to know whether your invocation of a PowerShell command worked? Well, it might be that the error stream has content, otherwise check the warning stream, otherwise check the regular output stream, and see if it contains an error-message-like-ish string 2. Continuing on this theme, just 'give me all the output, regardless of type/class, from this command' is just plain impossible. You want to see what this command would print on a terminal? Good luck with that! 3. Serializing PowerShell output to JSON (which, naively, you would assume would be sort-of reliable) generates heaps of PS*-specific junk. Just the common '|fl XXX' expression will trigger this 4. Even commands that appear to be successful, may in fact have failed. The Azure commandlets are especially guilty of this. Remove a load balancer NAT rule? Sure, we'll pretend to do that! Except, nothing happens, and you'll need a support ticket to actually modify your configuration
- majkinetor 4y ago
  Yeah, lets take 4 random things and yell around it sux.
  - PreInternet01 4y ago
    That's a remarkably insightful rebuttal. I sure see the errors of my way now. Except I'm not really sure whether these are in the Output, Error, Warning, Verbose or Debug stream, so...
    - majkinetor 4y ago
      It doesn't need insightful rebuttal :) But ... 1. *> is a thing 2. see above, I agree that Start-Transcript could be better and include all 3. Just provide your own massaged JSON 4. Not a pwsh problem, problem in general. For example take a look at Invoke-Builds `exec` as one way to handle this But really, 4 random things, and you don't like 2 decades of work. Awesome!
      - majkinetor 4y ago
        > 3. Just provide your own massaged JSON or use -Depth parameter...
      - felipelemos 4y ago
        > 1. > is a thing Silly how you need sh to do a very basic thing in PowerShell
        majkinetor 4y ago
        What? Did you think this trough? Give it another try.
- pathartl 4y ago
  The only point I would raise is that #1 isn't reliable on any system that has stdout/stderr. For most of the MS-created modules this is implemented correctly. You also have the ability to catch and throw exceptions... foreign to people who live in scripts but essential for people who have programming experience.
Pompidou 4y ago
I would agree, but by default powershell start and interactions are so slow (a boring unacceptable slowness!), that I prefer to use windows command or tcl wish for every day usages.
- majkinetor 4y ago
  While it can be faster, you must be using Commodore 64 or something. Or you have Defender running or something... It starts instantly, anything else is your local problem. Please stop spreading nonsence and learn to use your machine.
  - Havoc 4y ago
    It's slow AF on multiple machines my side too so he is not alone. >learn to use your machine. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - majkinetor 4y ago
      Yeah, its becoming ridiculous, but somebody needs to say it like it is. I, along with other people I am working with, used it on litterally thousands of different machines, during last decade. I think I have a pretty good experience about its speed, and while its not millisecond snappy, its not a picture you people are makig. If its slow, its a local problem, period. VM, AV, too many slow modules on autoload, slow profile, it could be a bunch of things. Now, you can keep whining for next decade, or fix your problem and stop this millenial shaneningas.
      - eviks 4y ago
        But I've fixed my problem by switching away from pwsh. You see, those "many modules" are what made pwsh usable
    - fuzzfactor 4y ago
      >learn to use your machine. I think consensus would more likely support "learn to keep your machine from using you".
eek2121 4y ago
I don’t. Reason: too wordy. Reminds me of Java.
- majkinetor 4y ago
  RTFM
smackeyacky 4y ago
I always felt that Powershell was a solid indication that the whole GUI-isation of the world that started with such a bang in the 1980s has been an impossible task to complete. For something as complicated as Windows Server, there is not enough time to build GUI screens and OLE/COM/DCOM interfaces for every little flag, function or feature. Microsoft must have realised this quite some time ago. The evidence? That even Windows 11 contains ancient, crufty GUI screens from Windows XP and older. It turned out the Unix guys were right all along. There is nothing wrong with the core of Windows as an operating system, but the baggage it carries mostly due to all those failed GUI screens makes it inferior in practice to Unix based systems. I have one powershell script I use, which is something that manipulates an Outlook mailbox. It's unreliable (thanks to Outlook) but again demonstrates what a pointless idea the entire Powershell project was and to a certain extent what a dead end things like systemd will eventually end up being.
- yarg 4y ago
  If you're building screens for every set of configurations that you're defining (and doing it a lot) then you're doing it wrong. If you can specify some sort of schema for configuration in general, then the screens can generally be generated. You generally don't want or need to display different instances of the same sort of configuration property in fundamentally different ways. I think that what you get from a (decent) GUI is discoverability of features, whereas what you get with the CL is specificity. The former makes computers accessible to the masses, the latter provides power to administrators.
  - kjellsbells 4y ago
    Reading this discussion I'm wryly reminded of IBM AIX and it's smitty tool. It let you administer AIX unix from a GUI, but always emitted the equivalent CLI command, as if GUIs were just something it hoped youd eventually grow out of.
hdaz0017 4y ago
{{(({{ CoNgRaTs On LiKiNg PoWeRsHeLl... It'S 2023 AnD HaS AlWaYs MaDe My EyEs BlEeD... }}))}} scripts are some 100x longer and normally break due to everything or anything changing...
- psd1 4y ago
  I just PR'd into a project that's a kludgy mess of bash. You can code-golf in Powershell. There are terse aliases. But generally the community doesn't do that. Looking at some of the bash garbage I've been subjected to, I'm glad. "normally break" yeah bad devs use bash too, trust me.
Havoc 4y ago
I don't mind powershell as such but the windows ecosystem it is in kills any desire I have to learn powershell. The "python" command in powershell triggering an app store popup even with python installed is the one that pushed me over the edge. I'll just remote into a *nix machine...
- pxc 4y ago
  That's actually a Windows thing, not a PowerShell-specific thing. The Microsoft Store app generates a stub executable called python.exe and puts it on your PATH. It'll get picked up whether you're in PowerShell, CMD, or MSYS2 Bash. It's basically the same kind of thing as Xcode's git stub on macOS (which I also find odious). The feature is called 'executable aliases', in case you want something to Google to find out how to disable it.
  - CoolCold 4y ago
    whoa! something new and makes some sense for newbies
pathartl 4y ago
Powershell has grown on me. Over time I've worn down and started utilizing my Windows install in the Windows way. I think Powershell is a well overlooked feature of the platform, to the point where I now have moved a lot of my scripts/automations on my home server (Linux based) from bash/js/.NET 7 binaries to Powershell Core. Big asterisk, my day job is as a .NET/C# developer. So much of Powershell does feel like a .NET wrapper or C#-lite, and that's not necessarily a bad thing. It lends itself very well to feeling like a traditional programming language. Hell, it even has a debugger! My only real complaint about it and adoption thus far is the release management. Windows 11 _still_ ships with 5.1, and 7 is leagues ahead in terms of performance and features.
majkinetor 4y ago
I cant understand why so many pwsh haters. Its literary light years away from any other shell. The comments are ridiculous as usual. This kind of behavior should be examined at adequate academia (when amazing thing is made and people think its shit, there shoud be some name for it).
- fuzzfactor 4y ago
  >when amazing thing is made and people think its shit, there shoud be some name for it I would call it un-called-for criticism. But I don't want to be too critical . . .
- Mountain_Skies 4y ago
  For people who are accustomed to the *nix world, PowerShell can feel like the uncanny valley of shells.
  - majkinetor 4y ago
    Thats because they are hypocrites. You can't separate *nix shell from awk, less, grep, jq, insert-whatever-little-tool-with-random-argument-parser-here. Once you do that, it feels like the uncanny universe of organic horrors. Don't get me wrong. Yey for the *nix stuff, I am huge fan. We wouldn't be here if that was absent. I am not working for MS or anybody that have stakes here. Its simply no comparrison.
jasoneckert 4y ago
As an ancient UNIX person, I've always loved PowerShell from the start. I remember the first time I played around with the first version that wasn't a download (2). I wanted to see how it dealt with objects, so I ran something simple: $ui = (Get-Host).UI.RawUI $ui | Get-Member (to see the methods and attributes available) $ui.WindowTitle = "Hello World Window!" After that, I was hooked. PowerShell providers and modules are incredibly useful, as is piping output to Out-GridView. Later versions have introduced more cmdlets that, quite honestly, everyone should use instead of DOS commands (e.g., Get-NetIPConfiguration instead of ipconfig). I do remember a bit of timing issues (often solved by inserting Start-Sleep) and other general flakiness like others have noted here, but the ones I've noticed were fixed in later versions.
- deafpolygon 4y ago
  I've been using some form of *nix since 1997? Pretty much since I had my first computer. I was very late to the party - didn't touch a computer until college! I've used Windows on and off throughout those years (gaming, mainly). Using PS is a joy, I've re-written all of my usual utility stuff from bash/zsh to PS inside a few week, and managed to improve on a bunch that I didn't want to do before because bash is painful to debug/test/etc. I rarely fire up WSL now, and it has replaced Python for my general utility scripting language. Note: if anyone is reading this - if you're still using PS5 built into W11, then you owe it to yourself to install PS7 (it can be installed alongside 5). It is invoked via pwsh rather than powershell, and can be setup to use the same startup scripts as the default PS.
ggorlen 4y ago
The author has a few good points. I want to love PS as well, but in practice it has too many gotchas and pitfalls that seem to pop up every time I write a script more than a few lines. Sure, all languages have these, but the ones in PS feel nastier and more subtle than most, compounded by the fact that it's not a language I use more than once every few months and should be easy to pick up and put down. Basic stuff like parens, commas, function calls, casting, variable interpolation and arrays are frequently surprising. Many behaviors fail silently. For example, arrays with 1 element behave differently than arrays with 2+ elements. PS is "smart" and treats the 1-element array as a scalar. Why? I've wasted hours dealing with arrays in PowerShell. See this post for a sampling of the problems: https://stackoverflow.com/a/69644807/6243352 https://stackoverflow.com/a/69644807/6243352 Even without the gotchas, case insensitivity, optional abbreviations, optional parens, etc, make PS scripts harder to read and debug than they need to be. PS feels like a mashup of many of the most confusing parts of PHP and Perl and adds its own fresh mess on top. Adding parameters and resolving a few of Bash's failings isn't much of an achievement given ~20 years of time to design it properly. Neither language is as easy to work with as it should be.
- Riverheart 4y ago
  If I had a nickel for every time I had to debug some crazy Bashism. PowerShell can be finicky at times but is a walk in the park compared to the alternatives. For basic stuff like if/else comparisons I don’t need to lookup how many parens or square brackets to use for strings or arithmetic or recall if 0/1 is true false or reverse. Maybe I should just compare “false”/“true” strings or use true/false commands instead which have their own issues. PowerShell has real functions, not just exit codes and text streams so you can easily write maintainable scripts past 100 lines. It’s got a debugger. It’s got modules and a package gallery. It’s got autocomplete and help messages. It’s got try/catch/finally instead of traps. It’s got an optional type system so you can be as loose or strongly typed as you want. It’s cross platform so the Windows devs don’t get confused migrating to Linux. It’s got batteries included for everything between cmdlets and .net. Anything you can do in C# can be replicated. Sed/awk/Grep are nice but sometimes you just want structured data converted into an object to pass around functions instead of reinventing the wheel. Case sensitivity is a feature, $foo and $Foo should be the same and if they’re not you should call it something different or invoke it differently. “$foo = new [foo]” separates variables from types. “$env:foo” namespaces your env vars. In Bash is FOO a var, constant or env var? Good PowerShell is readable with little effort. Good Bash is readable with significant effort if you are familiar with Bash and the problem domain already.
mlazos 4y ago
Powershell is incredibly powerful with | and %{} for transforming collections and SUPER simple .net integration. You can write commandlets in c#. It was one of the bright spots of my time at Microsoft.
zamalek 4y ago
I have used pwsh in depth in the past. 4-5 years ago when I was exclusively Windows, doing SharePoint, AD, Azure, etc. Also local utility scripts. I have used bash in depth over the past year, I maintain the local dev cluster tooling at work (because nobody else wants to, see: bash). It's about 2kloc of pretty advanced bash. While PowerShell is a terrible language, piping around text (or rather, let's face it, JSON) is objectively worse. I do feel more productive with the Bash language/syntax, but I have no faith in any code that I write. Bash is littered with footguns and odd behavior. I have been learning nushell recently and have been greatly enjoying it. You get to pipe around structures, while avoiding the obnoxious PowerShell syntax. As an example from today, I was double-checking that some envars made it into a container image: skopeo inspect ... --format json | from json | each { |x| $x.Env } Now that's certainly possible with bash and jq, but I'd probably be leaning on Google even after 1000s of hours of maintaining a bash behemoth.
eviks 4y ago
> You can do the default thing and write Get and press tab to cycle through things that start with Get. Except Tab is a lateral pinky key press, one of the worst key presses out there
- mst 4y ago
  It's also been the standard for that behaviour for shells and, well, lots of other things, for so long it won't change, and notice he also mentioned Ctrl-Space as an alternative. Though my hands don't complain so long as I don't use a mouse, so YMMV.
jiggawatts 4y ago
An often overlooked aspect of the "vision" of PowerShell is that it is intended to be the back-end of a GUI console! An good example is the Citrix management console. It is a very thin Windows GUI wrapper around a bunch of PowerShell modules. Literally everything it does, and everything it shows comes from PowerShell, not from direct API calls. When managing a Citrix farm remotely, it uses WinRM PowerShell remoting, not traditional COM+ RPC. This is easy because: 1. The PowerShell runtime can be trivially embedded into any .NET app. It's just a reference and about 3 lines of biolerplate. 2. It runs "in-process", making it much faster than calling out to external shells. 3. The commands are (relatively) strongly typed, so there's no concerns about escaping, shell injection, or other similar security issues. 4. Outputs come back as lists of strongly typed C# objects, making them trivial to bind to grid views or other GUI user controls. 5. Even tree views are easy to wire up, because PowerShell has a concept of virtual "drive" providers that can wrap anything in a file/folder structure. You just write a generic "folder and item navigator" GUI control once and then you can use it with any number of providers for free. The end-result looks like a traditional GUI, but basically guarantees that anything you can do in the GUI, you can also do in the shell. It's also ridiculously easy to add a "generate a script for this change" button, because it's just spitting out the internal representation!
_8j50 4y ago
Powershell is well...powerful and I can't say much bad about it. Bash scripting can be a pain but I like using bash scripts to chain together io from installed programs, the same task is difficult in powershell. Powershell lets you do stuff nicely if you stick to powershell modules and .net stuff. It's not very nice when wrangling output from $randomprogram. But regardless of platform I use bash or powershell usually for very small self-contained scripts and python for anything more extensive. I always say powershell is more akin to python or perl than bash except python never got around to making repl into a shell interpreter or nice things like script signing enforcement.

55 points by BerislavLopac 4y ago

(linux user): isn't Powershell that new slow as hell command prompt based on some .NET? No, thanks. It's just terrible as everything made of .NET.

tpoacher 4y ago

Nice article, and this is obviously a very specific nitpick from a single point in the article, but ... > ls --full-time | cut -d' ' -f6,7 # WRONG > If two “fields” have different lengths, ls will add spaces to the name of the smaller one to make the two line up, which will break cut -d' '. And in fact you can’t solve this at all with ls, you have to write stat -c %w. Text streams don’t compose. I mean, ok, I get the point how he's saying Powershell has 'objects', but the example is super-contrived. All it takes to fix the offending 'padding spaces' is to remove them. ls --full-time | tr -s ' ' | cut -d' ' -f6-7 Moreover, that's not even "bash" you're comparing against, but 'coreutils'. If you really wanted to grab the output of 'ls' with pure bash then you'd probably go with something like this instead: ls --full-time | while read -r FIELD{1..8}; do echo "$FIELD6 $FIELD7"; done which isn't exactly complicated either. Otherwise, if the gripe is about the command you're using not being field based, then go ahead and use one that is, on data that supports it. This isn't exactly a language issue. Case in point, if 'stat' is the right command to get that "field" for that "object type", then there you go. Nagging that if you don't use the right tool for the job will leave you with having to work around things, is not exactly the environment's fault. Also, text streams absolutely do compose. It's just that the underlying type will always be a text stream. But composability is 100% the reason behind this in the first place.

PreInternet01 4y ago

Well, I don't, and I'm a Windows fanboy. So, why, exactly none of you ask: 1. The PowerShell separation of, what on *ix* systems is stdout and stderr, doesn't really work. Want to know whether your invocation of a PowerShell command worked? Well, it might be that the error stream has content, otherwise check the warning stream, otherwise check the regular output stream, and see if it contains an error-message-like-ish string 2. Continuing on this theme, just 'give me all the output, regardless of type/class, from this command' is just plain impossible. You want to see what this command would print on a terminal? Good luck with that! 3. Serializing PowerShell output to JSON (which, naively, you would assume would be sort-of reliable) generates heaps of PS*-specific junk. Just the common '|fl XXX' expression will trigger this 4. Even commands that appear to be successful, may in fact have failed. The Azure commandlets are especially guilty of this. Remove a load balancer NAT rule? Sure, we'll pretend to do that! Except, nothing happens, and you'll need a support ticket to actually modify your configuration

majkinetor 4y ago
Yeah, lets take 4 random things and yell around it sux.
- PreInternet01 4y ago
  That's a remarkably insightful rebuttal. I sure see the errors of my way now. Except I'm not really sure whether these are in the Output, Error, Warning, Verbose or Debug stream, so...
  - majkinetor 4y ago
    It doesn't need insightful rebuttal :) But ... 1. *> is a thing 2. see above, I agree that Start-Transcript could be better and include all 3. Just provide your own massaged JSON 4. Not a pwsh problem, problem in general. For example take a look at Invoke-Builds `exec` as one way to handle this But really, 4 random things, and you don't like 2 decades of work. Awesome!
    - majkinetor 4y ago
      > 3. Just provide your own massaged JSON or use -Depth parameter...
    - felipelemos 4y ago
      > 1. > is a thing Silly how you need sh to do a very basic thing in PowerShell
      - majkinetor 4y ago
        What? Did you think this trough? Give it another try.
pathartl 4y ago
The only point I would raise is that #1 isn't reliable on any system that has stdout/stderr. For most of the MS-created modules this is implemented correctly. You also have the ability to catch and throw exceptions... foreign to people who live in scripts but essential for people who have programming experience.

Pompidou 4y ago

I would agree, but by default powershell start and interactions are so slow (a boring unacceptable slowness!), that I prefer to use windows command or tcl wish for every day usages.

majkinetor 4y ago
While it can be faster, you must be using Commodore 64 or something. Or you have Defender running or something... It starts instantly, anything else is your local problem. Please stop spreading nonsence and learn to use your machine.
- Havoc 4y ago
  It's slow AF on multiple machines my side too so he is not alone. >learn to use your machine. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - majkinetor 4y ago
    Yeah, its becoming ridiculous, but somebody needs to say it like it is. I, along with other people I am working with, used it on litterally thousands of different machines, during last decade. I think I have a pretty good experience about its speed, and while its not millisecond snappy, its not a picture you people are makig. If its slow, its a local problem, period. VM, AV, too many slow modules on autoload, slow profile, it could be a bunch of things. Now, you can keep whining for next decade, or fix your problem and stop this millenial shaneningas.
    - eviks 4y ago
      But I've fixed my problem by switching away from pwsh. You see, those "many modules" are what made pwsh usable
  - fuzzfactor 4y ago
    >learn to use your machine. I think consensus would more likely support "learn to keep your machine from using you".

eek2121 4y ago

I don’t. Reason: too wordy. Reminds me of Java.

majkinetor 4y ago
RTFM

smackeyacky 4y ago

I always felt that Powershell was a solid indication that the whole GUI-isation of the world that started with such a bang in the 1980s has been an impossible task to complete. For something as complicated as Windows Server, there is not enough time to build GUI screens and OLE/COM/DCOM interfaces for every little flag, function or feature. Microsoft must have realised this quite some time ago. The evidence? That even Windows 11 contains ancient, crufty GUI screens from Windows XP and older. It turned out the Unix guys were right all along. There is nothing wrong with the core of Windows as an operating system, but the baggage it carries mostly due to all those failed GUI screens makes it inferior in practice to Unix based systems. I have one powershell script I use, which is something that manipulates an Outlook mailbox. It's unreliable (thanks to Outlook) but again demonstrates what a pointless idea the entire Powershell project was and to a certain extent what a dead end things like systemd will eventually end up being.

yarg 4y ago
If you're building screens for every set of configurations that you're defining (and doing it a lot) then you're doing it wrong. If you can specify some sort of schema for configuration in general, then the screens can generally be generated. You generally don't want or need to display different instances of the same sort of configuration property in fundamentally different ways. I think that what you get from a (decent) GUI is discoverability of features, whereas what you get with the CL is specificity. The former makes computers accessible to the masses, the latter provides power to administrators.
- kjellsbells 4y ago
  Reading this discussion I'm wryly reminded of IBM AIX and it's smitty tool. It let you administer AIX unix from a GUI, but always emitted the equivalent CLI command, as if GUIs were just something it hoped youd eventually grow out of.

hdaz0017 4y ago

{{(({{ CoNgRaTs On LiKiNg PoWeRsHeLl... It'S 2023 AnD HaS AlWaYs MaDe My EyEs BlEeD... }}))}} scripts are some 100x longer and normally break due to everything or anything changing...

psd1 4y ago
I just PR'd into a project that's a kludgy mess of bash. You can code-golf in Powershell. There are terse aliases. But generally the community doesn't do that. Looking at some of the bash garbage I've been subjected to, I'm glad. "normally break" yeah bad devs use bash too, trust me.

Havoc 4y ago

I don't mind powershell as such but the windows ecosystem it is in kills any desire I have to learn powershell. The "python" command in powershell triggering an app store popup even with python installed is the one that pushed me over the edge. I'll just remote into a *nix machine...

pxc 4y ago
That's actually a Windows thing, not a PowerShell-specific thing. The Microsoft Store app generates a stub executable called python.exe and puts it on your PATH. It'll get picked up whether you're in PowerShell, CMD, or MSYS2 Bash. It's basically the same kind of thing as Xcode's git stub on macOS (which I also find odious). The feature is called 'executable aliases', in case you want something to Google to find out how to disable it.
- CoolCold 4y ago
  whoa! something new and makes some sense for newbies

pathartl 4y ago

Powershell has grown on me. Over time I've worn down and started utilizing my Windows install in the Windows way. I think Powershell is a well overlooked feature of the platform, to the point where I now have moved a lot of my scripts/automations on my home server (Linux based) from bash/js/.NET 7 binaries to Powershell Core. Big asterisk, my day job is as a .NET/C# developer. So much of Powershell does feel like a .NET wrapper or C#-lite, and that's not necessarily a bad thing. It lends itself very well to feeling like a traditional programming language. Hell, it even has a debugger! My only real complaint about it and adoption thus far is the release management. Windows 11 _still_ ships with 5.1, and 7 is leagues ahead in terms of performance and features.

majkinetor 4y ago

I cant understand why so many pwsh haters. Its literary light years away from any other shell. The comments are ridiculous as usual. This kind of behavior should be examined at adequate academia (when amazing thing is made and people think its shit, there shoud be some name for it).

fuzzfactor 4y ago
>when amazing thing is made and people think its shit, there shoud be some name for it I would call it un-called-for criticism. But I don't want to be too critical . . .
Mountain_Skies 4y ago
For people who are accustomed to the *nix world, PowerShell can feel like the uncanny valley of shells.
- majkinetor 4y ago
  Thats because they are hypocrites. You can't separate *nix shell from awk, less, grep, jq, insert-whatever-little-tool-with-random-argument-parser-here. Once you do that, it feels like the uncanny universe of organic horrors. Don't get me wrong. Yey for the *nix stuff, I am huge fan. We wouldn't be here if that was absent. I am not working for MS or anybody that have stakes here. Its simply no comparrison.

jasoneckert 4y ago

As an ancient UNIX person, I've always loved PowerShell from the start. I remember the first time I played around with the first version that wasn't a download (2). I wanted to see how it dealt with objects, so I ran something simple: $ui = (Get-Host).UI.RawUI $ui | Get-Member (to see the methods and attributes available) $ui.WindowTitle = "Hello World Window!" After that, I was hooked. PowerShell providers and modules are incredibly useful, as is piping output to Out-GridView. Later versions have introduced more cmdlets that, quite honestly, everyone should use instead of DOS commands (e.g., Get-NetIPConfiguration instead of ipconfig). I do remember a bit of timing issues (often solved by inserting Start-Sleep) and other general flakiness like others have noted here, but the ones I've noticed were fixed in later versions.

deafpolygon 4y ago
I've been using some form of *nix since 1997? Pretty much since I had my first computer. I was very late to the party - didn't touch a computer until college! I've used Windows on and off throughout those years (gaming, mainly). Using PS is a joy, I've re-written all of my usual utility stuff from bash/zsh to PS inside a few week, and managed to improve on a bunch that I didn't want to do before because bash is painful to debug/test/etc. I rarely fire up WSL now, and it has replaced Python for my general utility scripting language. Note: if anyone is reading this - if you're still using PS5 built into W11, then you owe it to yourself to install PS7 (it can be installed alongside 5). It is invoked via pwsh rather than powershell, and can be setup to use the same startup scripts as the default PS.

ggorlen 4y ago

The author has a few good points. I want to love PS as well, but in practice it has too many gotchas and pitfalls that seem to pop up every time I write a script more than a few lines. Sure, all languages have these, but the ones in PS feel nastier and more subtle than most, compounded by the fact that it's not a language I use more than once every few months and should be easy to pick up and put down. Basic stuff like parens, commas, function calls, casting, variable interpolation and arrays are frequently surprising. Many behaviors fail silently. For example, arrays with 1 element behave differently than arrays with 2+ elements. PS is "smart" and treats the 1-element array as a scalar. Why? I've wasted hours dealing with arrays in PowerShell. See this post for a sampling of the problems: https://stackoverflow.com/a/69644807/6243352 https://stackoverflow.com/a/69644807/6243352 Even without the gotchas, case insensitivity, optional abbreviations, optional parens, etc, make PS scripts harder to read and debug than they need to be. PS feels like a mashup of many of the most confusing parts of PHP and Perl and adds its own fresh mess on top. Adding parameters and resolving a few of Bash's failings isn't much of an achievement given ~20 years of time to design it properly. Neither language is as easy to work with as it should be.

Riverheart 4y ago
If I had a nickel for every time I had to debug some crazy Bashism. PowerShell can be finicky at times but is a walk in the park compared to the alternatives. For basic stuff like if/else comparisons I don’t need to lookup how many parens or square brackets to use for strings or arithmetic or recall if 0/1 is true false or reverse. Maybe I should just compare “false”/“true” strings or use true/false commands instead which have their own issues. PowerShell has real functions, not just exit codes and text streams so you can easily write maintainable scripts past 100 lines. It’s got a debugger. It’s got modules and a package gallery. It’s got autocomplete and help messages. It’s got try/catch/finally instead of traps. It’s got an optional type system so you can be as loose or strongly typed as you want. It’s cross platform so the Windows devs don’t get confused migrating to Linux. It’s got batteries included for everything between cmdlets and .net. Anything you can do in C# can be replicated. Sed/awk/Grep are nice but sometimes you just want structured data converted into an object to pass around functions instead of reinventing the wheel. Case sensitivity is a feature, $foo and $Foo should be the same and if they’re not you should call it something different or invoke it differently. “$foo = new [foo]” separates variables from types. “$env:foo” namespaces your env vars. In Bash is FOO a var, constant or env var? Good PowerShell is readable with little effort. Good Bash is readable with significant effort if you are familiar with Bash and the problem domain already.

mlazos 4y ago

Powershell is incredibly powerful with | and %{} for transforming collections and SUPER simple .net integration. You can write commandlets in c#. It was one of the bright spots of my time at Microsoft.

zamalek 4y ago

I have used pwsh in depth in the past. 4-5 years ago when I was exclusively Windows, doing SharePoint, AD, Azure, etc. Also local utility scripts. I have used bash in depth over the past year, I maintain the local dev cluster tooling at work (because nobody else wants to, see: bash). It's about 2kloc of pretty advanced bash. While PowerShell is a terrible language, piping around text (or rather, let's face it, JSON) is objectively worse. I do feel more productive with the Bash language/syntax, but I have no faith in any code that I write. Bash is littered with footguns and odd behavior. I have been learning nushell recently and have been greatly enjoying it. You get to pipe around structures, while avoiding the obnoxious PowerShell syntax. As an example from today, I was double-checking that some envars made it into a container image: skopeo inspect ... --format json | from json | each { |x| $x.Env } Now that's certainly possible with bash and jq, but I'd probably be leaning on Google even after 1000s of hours of maintaining a bash behemoth.

eviks 4y ago

> You can do the default thing and write Get and press tab to cycle through things that start with Get. Except Tab is a lateral pinky key press, one of the worst key presses out there

mst 4y ago
It's also been the standard for that behaviour for shells and, well, lots of other things, for so long it won't change, and notice he also mentioned Ctrl-Space as an alternative. Though my hands don't complain so long as I don't use a mouse, so YMMV.

jiggawatts 4y ago

An often overlooked aspect of the "vision" of PowerShell is that it is intended to be the back-end of a GUI console! An good example is the Citrix management console. It is a very thin Windows GUI wrapper around a bunch of PowerShell modules. Literally everything it does, and everything it shows comes from PowerShell, not from direct API calls. When managing a Citrix farm remotely, it uses WinRM PowerShell remoting, not traditional COM+ RPC. This is easy because: 1. The PowerShell runtime can be trivially embedded into any .NET app. It's just a reference and about 3 lines of biolerplate. 2. It runs "in-process", making it much faster than calling out to external shells. 3. The commands are (relatively) strongly typed, so there's no concerns about escaping, shell injection, or other similar security issues. 4. Outputs come back as lists of strongly typed C# objects, making them trivial to bind to grid views or other GUI user controls. 5. Even tree views are easy to wire up, because PowerShell has a concept of virtual "drive" providers that can wrap anything in a file/folder structure. You just write a generic "folder and item navigator" GUI control once and then you can use it with any number of providers for free. The end-result looks like a traditional GUI, but basically guarantees that anything you can do in the GUI, you can also do in the shell. It's also ridiculously easy to add a "generate a script for this change" button, because it's just spitting out the internal representation!

_8j50 4y ago

Powershell is well...powerful and I can't say much bad about it. Bash scripting can be a pain but I like using bash scripts to chain together io from installed programs, the same task is difficult in powershell. Powershell lets you do stuff nicely if you stick to powershell modules and .net stuff. It's not very nice when wrangling output from $randomprogram. But regardless of platform I use bash or powershell usually for very small self-contained scripts and python for anything more extensive. I always say powershell is more akin to python or perl than bash except python never got around to making repl into a shell interpreter or nice things like script signing enforcement.