7 ms·

I've always been curious to know. I am an experienced Bash developer, and when PowerShell was released, I was very excited. Finally, we would have a cool shell

• pletnes 2y ago
  Exactly my experience.
• langcss 2y ago
  I find it is in a weird spot where it is more powerful than bash but you often don't need that power or if you do coding in c# might be better. It is very good of you want to work with Azure though. You probably don't want to use bash for that. But lots of reading up each time I use it. Bash is my go to for small jobs or a command line experience. I am not an expert in either but have used both plot to get stuff done.
  • simooooo 2y ago
    Most times if I’m doing anything suitably complex it ends up as a little C# app rather than powershell.
• prmoustache 2y ago
  Well I used powershell a lot when I was managing VMWare infra. Ultimately the force of a object oriented shell is in the ecosystem, I haven't found any other use case where powershell was useful to me. I am pretty sure it is useful in an Azure context too but in the last few years I have never been in a situation where I would feel the need to install powershell on my linux workstation to use a specific module/use case.
• sebstefan 2y ago
  I've done a lot of Bash, read some books about it, I'm a firm believer that nobody should be writing anything complex in bash. Above the ballpark of 50 lines I consider it a code smell. I have this web page saved up in case I ever need to convince anyone of this. http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls I used Powershell recently and not having to wrangle with text (commands return objects) makes it a much easier scripting language, and command line language. The fact that they have an official way to handle argument parsing is excellent, everything is unified and the commandline window is able to have autocompletion for literally every option of everything. Bash could never even dream of having that. It is incredible and makes you extremely productive. But type coercion manages to introduce new ways to create bugs that Bash didn't have. Honestly at this point I prefer PWSH but still kinda dislike both. I'm waiting for the new natural evolution.
  • sebstefan 2y ago
    I forgot but one thing I also liked that made me go "Why would bash not have that?" is having a dedicated verbose,info,warn,error,debug output and a glob star *> to redirect everything. It's nice not having verbose text polluting stderr.
  • PeterWhittaker 2y ago
    > I have this web page saved up in case I ever need to convince anyone of this... http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls This is a great list of pitfalls, absolutely, but they are more an argument for integrating shellcheck into your IDE than avoiding bash, IMHO! I know, I know, possible religious war, but I find that bash+shellcheck is far more often the right toolset than switching languages to avoid the pitfalls. The immense power and expressiveness and immediacy of bash makes so many programs and so much prototype->PoC->MVP progression so easy and effortless that it is worthwhile having tooling to catch the worst of the warts.
    • jonhohle 2y ago
      Add shunit or similar and I You can have a really nice experience (imho).
• PeterWhittaker 2y ago
  I started my career with a X term hosted on a SunOS pizza box, have written thousands of scripts, more than a few in the KLoC count. Several years ago, I had to write a complex unattended robust data transfer system in PowerShell. (I know, I know, without more info these “requirements” beg many questions, but they are all out of scope for this reply.) I enjoyed the experience so much I switched all my shells, on MacOS (my DD) and on Linux (my most common work environments) to PWSH. What I liked most about it was the power of passing objects in pipelines, and being able to extract/manipulate some of the properties of an object in the first filter and still have access to others, along with those of objects created by that first filter, in filters later in the pipeline. Immensely powerful. The consistency of commands, of error handling, and of object properties was also very nice. Eventually, as the nature of work changed I switched all shells back to bash, as the older muscle memory asserted itself. PWSH as a shell made sense when I was working and thinking so much in that space, but when I left it, it was more effortful to think in PWSH than to resume bash. There are times I miss it. There is nothing else in the shell space that comes close, or at least not close enough to justify the effort of switching.
  • ethbr1 2y ago
    Do you remember what the common commands for pipelining you used were? I feel like my PowerShell struggles are really about not knowing 2-5 core, general-purpose pipelining commands well enough to use in any situation.
    • valiant55 2y ago
      Get-ChildItem, Select-Object, Where-Object, Sort-Object or anything that is operating on a collection feel very natural. Often times I'm piping Get-ChildItem into sort to find the most recently created file in a directory.
    • jodrellblank 2y ago
      |? PropertyName -gt 5 # where-object filter numbers |? PropertyName -match 'text' # where-object filter text |? {$_.thing ...} # where-object filter script |% PropertyName # same as select-object -expandproperty propertyname |% { $_.thing } # foreach loop |sort |sort prop1, prop2 |sort {$_.Name.Substring(0,5) -as [int]} # sort calculated thing |fl * # format-list , all properties |ft -auto # format-table, autosize table column widths |sv q # set-variable -name q, same as $q = <...> |tee -var q # same but show the results as well as storing in q
• Kwpolska 2y ago
  PowerShell is more verbose than Bash, and has its idiosyncrasies (like sometimes automatically unwrapping 0/1-element arrays into scalars when you least expect it), but it is more productive and more readable. Object-orientation can be nice to produce pipelines. For example: find potential file duplicates in a folder, recursively, by grouping by file size: Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count No need to remember arcane `file` incantations, no need to parse textual output. You get real objects with properties, and tab completion can see their structure. Need to parse JSON? No need to involve `jq`, just `Get-Content -Raw whatever.json | ConvertFrom-Json` and do it directly from PowerShell. Need to convert XML into CSV? ConvertFrom-Xml (or Select-Xml) -> do stuff -> ConvertTo-Csv. Is `Get-ChildItem` too much typing? Use `gci`, or `dir`, or `ls` (by default only on Windows). Is `Where-Object` too much? Try `where` or `?`. And things are case-insensitive.
  • g15jv2dp 2y ago
    You can even simplify your `Where-Object` as ... | Where-Object Count -gt 1 | ... Or, of course, ... | ? count -gt 1 | ...
  • akira2501 2y ago
    ...and how do I get a "manual page" for the command "Get-ChildItem" in the console?
    • Miner49er 2y ago
      Get-help get-childitem
      • TeMPOraL 2y ago
        Also remember to check Get-Help Get-Help. Also, unfortunately, you'll probably want to Update-Help first, because for reasons beyond my comprehension, PowerShell does not ship with detailed help installed by default.
    • BanazirGalbasi 2y ago
• Joel_Mckay 2y ago
  [flagged]
  • nullindividual 2y ago
    > GUI by their very nature usually make "simple things easy, and difficult things impossible". Creating an Active Directory forest was traditionally done via a GUI wizard. I would say that makes a very complex task easy, where-as creating it via CLI requires some amount of knowledge, making something otherwise easy "difficult" as you need to know what the CLI parameters are asking for (GUI explains it in plain <localized language>), _and_ you need to know what the proper cmdlet is, leading to difficulty in discovery. Server Manager starts automatically after logging into Windows Server for the first time, presenting the user with a two-click method to start the deployment of AD (and some more clicks for the wizard itself). This lets anyone, from an SMB one-person shop to the largest company in the world (who is that?) deploy AD in a matter of minutes. It's empowering. Equating Win Admins with chickens is rather disrespectful and/or elitist. "Don't get mad, bro!" doesn't absolve one of their statement. I've written PowerShell modules in C# for SharePoint Server. I continue to use the click-click-next-finish GUI for certain tasks. Does that make me a troglodyte? [0] https://learn.microsoft.com/en-us/powershell/module/addsdeployment/install-addsforest?view=windowsserver2022-ps#example-1-install-a-new-forest https://learn.microsoft.com/en-us/powershell/module/addsdepl...
    • Joel_Mckay 2y ago
      The point was things like AD are not really transparent to the end user, and thus difficult to handle in a CLI outside of a utility (usually need privileged MS insider OS API documentation). As a side note, exposing a desktop environment in a server role is still a problem 30 years later (GUI usually slowly leak memory over time.) Note chickens are fairly aggressive little creatures, and through the power of Cortana could easily masquerade as an admin. Thus, one has to be careful when you see sharp peckers. Have a wonderful day, =3
      • nullindividual 2y ago
        > thus difficult to handle in a CLI outside of a utility (usually need privileged MS insider OS API documentation) There's a CLI command for it! What are you talking about with regards to APIs needed to do the particular task I mentioned? > (GUI usually slowly leak memory over time.) No, no, no, no. Please don't make up false statements to try to "prove a point". You're just being disrespectful to be disrespectful. You're disrespectful of many talented individuals in the industry. For shame.
• omnicognate 2y ago
  No expert in either but I've had to use both a fair amount. Powershell fell into a few traps that rendered it awful to use IMO: * Trying to be a .NET language. I don't know why the one-runtime-many-languages promise of .NET withered on the vine while it flowered in Java-land without the promise even having been made, but it did. If you're writing .NET code, use C#. (And I say that having worked in one of the very few teams doing large scale development in F#.) * Failing to get the basics of being a shell right. I can't remember the details as I've left it firmly in the past now, but its handling of redirection was just broken, to the extent that things that were trivial in bash were nigh on impossible in powershell. I got the impression its developers ignored the things bash etc. did well in their enthusiasm over building something new and powerful. * Being fetishistic about stuff like requiring Verb-Object naming for everything. It's certainly subjective and has its defenders, but IMO it renders scripts ugly, is awkward to type and doesn't materially improve discoverability or memorability at all.
  • Kwpolska 2y ago
    PowerShell isn't quite a .NET language, and you can't really write serious .NET software in PowerShell. But if you need to access the power of .NET (or heck, COM) from a script or an interactive shell, PowerShell lets you do that.
    • omnicognate 2y ago
      That's the point, though. It's a bad .NET language, but the desire to interact with .NET dictated much of its design. Windows didn't need a way to "access the power of .NET". It needed a decent shell, and sadly still lacks one Edit: And that isn't to say .NET doesn't need a scripting language. It sorely needs that and the various relatively useless variants on "C# scripting" are testament to that. Powershell isn't, and doesn't even attempt to be, a solution to that lack, though.
      • neonsunset 2y ago
        To be fair, nothing in .NET required Powershell to make the choices it did (case in point: F#, ClojureCLR) for the integration. I wish to learn it but it being so...wordy definitely makes it an unattractive choice. A shell should be terser than F# or C#, not the other way around.
• bionhoward 2y ago
  I don’t like powershell because it’s so surprising in a billion ways from bash. The tab being replaced with right arrow screws me up, and so does not having the normal commands, and it’s quite opinionated about naming. That said, powershell seems more capable than bash if you know it well, because it has a better type system and arguments are easier to mess with, whereas bash things are amorphous strings. https://github.com/bionicles/tree_plus/blob/main/tests/more_languages/group6/Microsoft.PowerShell_profile.ps1 https://github.com/bionicles/tree_plus/blob/main/tests/more_... That’s a slightly out of date version of what I use to provision stuff on my windows machine to test things, and can show what’s possible a bit.
• drsopp 2y ago
  I used a Powershell-script in a recent project and learned some lessons. It gets some data from an API. It is run dozens of times every minute, can run concurrently with itself, has some writing to a json file cache in a race condition free way. Works mostly ok. Development has been difficult because of low volume of forums talking about Powershell. Wouldn't have bothered to make the script without ChatGPT. One time it failed by inexplicably setting system+hidden+read only flags in a project folder. Quite a head scratcher. The worst experience was a bug I still don't understand: The script failed to get an access token when running in "ordinary powershell" but managed to do so when running in Powershell ISE. I checked every possible environment difference and concluded that there was only one: powershell.exe vs powershell_ise.exe. I am not going to be making any more Powershell scripts.
• GrantMoyer 2y ago
  I use *sh at home, and Powershell at work. Powershell has a lot of really cool and genuinely useful concepts. There's the obvious like piping objects instead of raw bytes, but there's also things like first class parameter validation, automatic array flattening, multi-threading, full .NET API interoperation, and more. Unfortunately, it also has some real sore points for use as an interactive shell, and even some outright broken behavior. Some that I lament most frequently: - Powershell has native tab-completion support, but the word-of-god dictated "Verb-Noun" command naming scheme means almost every command shares a common prefix with a slew of entirely unrelated commands, making tab-completion painful. - Power shell has sparse built-in support for funtional style list manipulation or data structures beyond lists. There's a "map" command (%), but no reduce, zip, tail, etc. These feel like they'd fit in perfectly to the design of the language, but they're just missing. Also, pipes are lazy, but lists are always strict, which can cause friction. - most operators are strangely named, such as "-eq" for ==, which hurts legibility. - There're lots of unvoidable brackets, meaning you often need to jump around the line while writing out a command incrementally. For example, to get filenames, you either need to write `(Get-Item).Name` or `Get-Item | %{$_.Name}`. It'd be nice to have something like `Get-Item |. Name` as an option. - It's impossible to pipe raw bytes between commands/executables; raw bytes are interpreted as strings. This means, for example, it's impossible to pipe a file to `patch`, because the contents will be decoded into strings, piped as strings, then re-encoded with line endings changed, which `patch` rightfully refuses to apply. - Running Powershell scripts is disabled by default (WTF?) By comparison, *sh's heavily favor interactive use. For example, you can put io redirections at the start or end of a line, tab-completion is often very good, it's often possible to avoid brackets (ex. with xargs), background/foreground job management, etc. Overall, I often find Powershell more pleasant to use than *sh, especially when writing scripts. But for interactive use, I often wish Powershell was a little smarter and a little dumber at the same time.
  • nu11ptr 2y ago
    Why is automatic array flattening a good thing? This has caused more bugs than I can count. Every time I make an array I have to check if it has a length of 1 and do something special with it or else the script blows up. Best I can tell this is a huge foot gun anti-feature. What am I missing?
• marcosdumay 2y ago
  A shell is not a thing by itself. It's only as good as it integrates with the rest of the system. So, the experience of PowerShell on Windows is unbeatable... on Windows. It's easily beaten on any other system.
• delta_p_delta_x 2y ago
  I'm not an expert, but I use UNIX/Linux at work and only Windows at home (I have a dormant Arch Linux install that I haven't touched in a couple of years), and hopefully you think I'm qualified to respond. I feel Bash is a 'glue language' in every sense of the word, and is optimised for interactive command-line usage because of its terseness. Being remotely productive on Bash presupposes the presence of an entire UNIX subsystem and coreutils (which is why Git Bash for Windows drags along an entire `/usr/bin` directory with all the coreutils in it). You can't really do much in it without the coreutils. I find that Bash parseability and ease-of-understanding rapidly deteriorates in scripts of increasing complexity. After about a hundred lines of code I reach for other languages. I personally dislike its unintuitive syntax, global scope, and weak, dynamic typing. The terseness that lends itself to powerful interactive command-line usage means script readability plummets. Of course, that might just mean I'm inexperienced with respect to Bash and need more practice, but I find this a fairly common opinion amongst colleagues and friends. In my opinion, Bash scripts are write-only. It is a wonder that something like neofetch[1]—which is an eleven thousand-line monstrosity—lasted this long (if I recall correctly the author stopped maintaining it because—amongst other reasons—it had just become too complicated). I find that people understand PowerShell better when they realise it is closer to Python than any interactive UNIX shell. By default, PowerShell is more verbose than Bash; for instance, the PowerShell equivalent of the two-character all-lowercase `ls` is the thirteen-character mixed-case `Get-ChildItem`. Arguments are by default also long and verbose, with things like `-FollowSymlink`. PowerShell is generally meant to be used in executable scripts, just like how most Python isn't executed in the interactive REPL, but by running scripts. Consequently, I find this verbosity lends itself to improved readability in scripts, at the expense of some interactive productivity. That being said, common PowerShell commands have UNIX-like aliases[2] (at one point the cause of much gnashing of teeth here and at /r/programming because PowerShell aliased `curl` to `Invoke-WebRequest`[3]) to improve interactive productivity. PowerShell also supports truncating parameter names; for instance, `Get-ChildItem -Recurse -Force` can be abbreviated to `gci -r -fo`, which looks remarkably like a UNIX command now. Even so, the PowerShell ISE and the PowerShell VS Code extension both suggest that programmers use the full unabbreviated commands and arguments in `.ps1` scripts[4]. PowerShell is also dynamically typed, though semi-static typing can be opted in to[5]. That said there is some controversy about arrays decaying to scalars when they have size 1 [6]. It is easy to set up both function and script parameters with as much power and expressiveness as `argparse` for Python, but natively without involving any additional modules[7]. The real power (pun not entirely unintended) of PowerShell comes when you realise it is just another front-end to the incredibly massive .NET ecosystem. Where Bash requires a full UNIX subsystem and a collection of hundreds of additional binaries to be productive, PowerShell employs pre-compiled cmdlets[8] written in .NET (usually C#) to augment the basic language. Most 'commands' in PowerShell are cmdlets, including `Get-ChildItem`. You can write your own 'back-end' in C#, F#, C++/CLI, VB, or any other .NET language, compile it, and expose a PowerShell interface for end-users. Pretty much like how people write fast but complex code in C/C++, compile it, and expose a Python interface (Numpy, Pandas, PyTorch, etc come to mind). You can additionally directly call .NET methods in PowerShell[9]. This also means that everything in PowerShell is an object. The output of `Get-ChildItem` is a list, not a string. Likewise for `Get-Process` (UNIX equivalent: `top`). These lists may be formatted[10], filtered, parsed, modified, dumped to JSON, and otherwise manipulated like any other list data type in most other languages. PowerShell also lends itself to the side-effect-free/functional/monadic map-reduce paradigm very well, with pipelines[11]. In my opinion, it is not merely 'better than CMD'; it blows CMD out of the water. A little less so for Bash, because Bash is augmented by the UNIX core-utils. As should now be evident, in my view the real competition to PowerShell is Python. [1]: https://github.com/dylanaraps/neofetch/blob/master/neofetch https://github.com/dylanaraps/neofetch/blob/master/neofetch [2]: https://learn.microsoft.com/en-us/powershell/scripting/learn/shell/using-aliases?view=powershell-7.4#compatibility-aliases-in-windows https://learn.microsoft.com/en-us/powershell/scripting/learn... [3]: https://news.ycombinator.com/item?id=12319670 https://news.ycombinator.com/item?id=12319670 [4]: https://learn.microsoft.com/en-gb/powershell/utility-modules/psscriptanalyzer/rules/avoidusingcmdletaliases?view=ps-modules https://learn.microsoft.com/en-gb/powershell/utility-modules... [5]: https://stackoverflow.com/a/115815/1654223 https://stackoverflow.com/a/115815/1654223 [5]: https://superuser.com/a/414666/1132163 https://superuser.com/a/414666/1132163 [7]: https://learn.microsoft.com/en-gb/powershell/module/microsoft.powershell.core/about/about_parameter_sets?view=powershell-7.4 https://learn.microsoft.com/en-gb/powershell/module/microsof... [8]: https://learn.microsoft.com/en-gb/powershell/scripting/powershell-commands?view=powershell-7.4 https://learn.microsoft.com/en-gb/powershell/scripting/power... [9]: https://devblogs.microsoft.com/scripting/learn-how-to-use-net-framework-commands-inside-windows-powershell/ https://devblogs.microsoft.com/scripting/learn-how-to-use-ne... [10]: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/format-table?view=powershell-7.4 https://learn.microsoft.com/en-us/powershell/module/microsof... [11]: https://learn.microsoft.com/en-gb/powershell/module/microsoft.powershell.core/about/about_pipelines?view=powershell-7.4 https://learn.microsoft.com/en-gb/powershell/module/microsof...
• nunez 2y ago
  I was extremely well versed in PowerShell early into its development. It was indispensable when it came out. VBscript and Cygwin were the only options; both of them sucked. The ability to use native .NET objects in scripts was insane; I definitely abused that! Nowadays, Git Bash and WSL2 replace a lot of the value that PowerShell provided. It's purpose was to drive Microsoft away from the GUI, and, at that, it more than succeeded.
  • oblio 2y ago
    > VBscript and Cygwin were the only options; both of them sucked. I'd challenge the Cygwin aspect. With judicious use of cygpath & co., you can go VERY far with Cygwin. I've built an entire SaaS deployment system on top of it (and Python).
• gonzo41 2y ago
  I just find everything about powershell tricky. Something just doesn't click for me. It's always a struggle.
• dfedbeef 2y ago
  Powershell is a huge improvement over cmd. However; much like Windows, it is full of complicated gotchas and edge cases. Bash has them too, but Bash makes concurrency and parallelization extremely simple, so despite it's absolutely bananas syntax and rules for hash tables and arrays, it is superior IMO. Bash also makes it simple to write your own more complex utilities in any language and call them from bash. Linux makes it simples to implement new kernel tech and Bash makes it simple to interact with the kernel. Windows... You have to wait until someone in WDG decides some existing idea is good and then also wait for them to get support to implement the idea, then wait to see how that whole thing goes. So yeah Powershell is great for interacting with Windows. But Windows thinks you're a dumb shit so you can only do what Windows already lets you do.
• ed_elliott_asc 2y ago
  It took me about a decade to be comfortable with it :)
• zamalek 2y ago
  I have used it for nontrivial stuff. The idea of streaming objects has a lot of potential, but I think the "enterprise crowd" had a really good crack at it - especially the syntax. Not having to resort to grep, jq, cut, and the host of tools required to (often fragile) parse out whatever specific format the tool you are calling is giving you. Put another way, you could feel free to parse the output of ls in powershell - because it's already been done for you.
• rewgs 2y ago
  They should have called it PowerScript, because it's a perfectly decent scripting language and an absolutely horrendous interactive shell language.