4 ms·

Doesn’t have all the author’s desired features out of the box, but recently I was forced into using PowerShell (Core edition, which is OSS, different from Windo

Doesn’t have all the author’s desired features out of the box, but recently I was forced into using PowerShell (Core edition, which is OSS, different from Windows only pwsh) for a work project and you know what? It’s surprisingly capable! It’s available from powershell/powershell on GitHub as a built binary for multiple systems and architectures including MacOS and Linux, or you could compile it yourself since it’s open source. The powershell gallery is the marketplace this guy was talking about, so there’s that. And you can distribute or consume fully encapsulated modules as well. The scripting language itself is fully object oriented, and while it takes some getting used to, you quickly start seeing real value in your day to day from the conventions and patterns established by the community over the years. I haven’t switched entirely from zsh yet, but I’m slowly investigating exactly how to do that as time allows. It’s a bit more verbose than typical Unix shells so you type a little more, but that’s a small price to pay for everything it brings to the table. If you’ve never tried it (OSS version, aka “core” edition) I highly recommend it. WAY easier to learn for first timers than bash!

pjmlp 5y ago
It is builds up on top of Xerox PARC ideas regarding REPL and OS integration. UNIX systems could offer similar integration, via IPC mechanisms, KParts and DBus like communication, exposing shared libraries directly into the shell and structured data. Where it fails down is lack of standardization across the landscape, so that everything actually works together.
thibran 5y ago
Did you try out Nushell, what do you think about it in comparison to PowerShell?
pxc 5y ago
Fish has taught me that I should strongly prefer shells with batteries included when it comes to interactivity, and Elvish has beautifully demonstrated how that can be taken even further with things like its built-in navigation mode. PowerShell's big weakness, imo, is that it lacks that emphasis on interactivity OOTB, and configuring it back in often results in astonishingly bad performance. That said, the language is way better than any traditional Unix shell, and the ecosystem of libraries and scripts is insanely comprehensive. Together, these factors make for an absolutely top-notch scripting experience. This is definitely one of the the biggest sources of inspiration for most next-gen Unix shells afaict.
partdavid 5y ago
I've found that as you learn, the verbosity kind of fades away, because you adapt your aliases and patterns to your work habits. The small amount of remaining "extra" verbosity that remains is very worth it, because it gives you more discoverability and more consistent ways of handling data in exchange. I would probably rephrase your statement about object-orientation: I don't think Powershell is particularly object-oriented, but it integrates nicely with object-oriented .NET. What I mean is: when writing extensions to Powershell in Powershell, you may use objects incidentally as containers for structured data, or occasionally to access details in .NET, but you are not creating objects or classes--you're working with functions in a straightforward way, and it's easy to make your functions behave like (take the same options in the same way as) "standard" commands. I switched (completely) a couple of years ago. The main "use case" that is Powershell's sweet spot for me is handling structured data. A lot of my operations have steps like: Do some data-wrangling to calculate a URL and request options for some data repository or integrated system API; Perform a network call or look something up in a big file of structured data; Munge and wrangle that data to extract information or calculate summaries; Perform more network calls based on that data and do further munging and calculating. This is usually discovery-oriented, interactive, ad-hoc lightweight integration, and it's in an environment where I'm doing something with this data (like figuring out a machine list from a couple of CMDBs, cross-referencing that with data from the monitoring system and maybe some lookups for system roles, and then performing commands on them). It's not a great fit for a "real" scripting language because the stuff about processing the data and doing the network calls is intermixed with lots of stuff that the "real" scripting language is not very good at, like interactively discovering what's in the data, invoking a bunch of OS commands and putting things together left-to-right in a pipeline you craft gradually. As your activity matures (you find yourself doing the same thing over and over), you can start factoring your code into reusable units, but not all of it, and Powershell is just super excellent at tasks at this boundary, because it's just fine as a programming language in its own right (much more capable than bash, and with goodies that you reference, like having dependency management) while being at least as good an interactive shell as bash. As a "Unix guy", I favor a lot of Unix-isms so of course I customize my shell heavily. I can do more powerful things in my prompt much more easily than with bash. I like the more familiar bash-style tab-completion than Powershell's, so I use the PSReadLine module settings to enable that. I use vi keys for command-line editing (with remapped cursor motion keys) and getting this done is easier to accomplish than doing so in bash. I don't like some of Powershell core's default aliases (like curl--I want curl to invoke the curl command, and I'll use iwr instead of curl when I want Invoke-WebRequest), so I disable them. I do all of my professional work on MacOS and Linux and Powershell is a good shell on both, and almost all of my experience with Powershell is as a Unix shell. I'm not much of a fan of commitment to the so-called "Unix philosophy", but I do think that Powershell reflects this philosophy better than a typical Unix shell and Unix commands. For example, once you learn how to sort the output of ls according to its standard options, all you've learned is something about the ls command. It doesn't help you in sorting a process list from ps. It also doesn't help you in sorting files by something other than size (-S), mtime (-t), atime (-u sort of), "natural version in the name (what?)" (-v), or alphabetically by extension (-X). According to the "Unix philosophy" what is the ls command even doing parsing and sorting version numbers anyway? In Powershell, it's more natural to let Sort-Object sort things, which it can do by any of the item's fields, not just what the ls author provided an option for; and once you know you can do that, you can do it for processes in just the same way, or AWS instances or anything else. Boom. Unix philosophy. (And if you just like using ls, and piping it to sort, that works fine, too, so no custom is imposed on you). It's kind of beautiful. Our views on what we want out of a shell are always based on the tasks we personally try to accomplish with it, and I don't think the author wants a "better shell" at all, but a better, more scriptable IDE. His "use cases" for the shell are all elementary file management and command invocation and he doesn't really seem clear on which component of his system the shell actually even is. Interestingly, there is a full TUI framework for Powershell and it's pretty cute! I didn't know about it before looking it up after reading this article.
Jenk 5y ago
I still find it grating with how pipes are handled. E.g. git ls-files --exclude-standard -o | For-Each { Remove-Item $_ } Just.. _why_ do I need that For-Each?! (Deliberately not using aliases for clarity)
- tyingq 5y ago
  As far as I can tell, you don't need it if you're piping the right stuff to Remove-Item C:\temp\foo> dir Directory: C:\temp\foo Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 9/10/2021 1:03 PM 0 thing1 -a---- 9/10/2021 1:03 PM 0 thing2 -a---- 9/10/2021 1:03 PM 0 thing3 C:\temp\foo> dir thing* | Remove-Item C:\temp\foo> dir C:\temp\foo>
  - Jenk 5y ago
    dir works because it's actually an alias of Get-ChildItem, which returns a list of objects (DirectoryInfo or FileInfo). My example was specifically a list of paths that are not objects but just strings.
    - tyingq 5y ago
      Okay. How about "echo"? (Aliased to Write-Output, which I assume is strings) C:\temp> dir file3 Directory: C:\temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 9/10/2021 1:03 PM 0 file3 C:\temp> echo "file3" | Remove-Item C:\temp> dir file3 dir : Cannot find path 'C:\temp\file3' because it does not exist. Edit: I see it now. It works with one string, but if I Write-Output "file1`r`nfile2" | Remove-Item it no longer works because it takes the whole string as an object. I'd have to pipe an array of strings rather than cr-lf separated strings. This does work: C:\temp> $foo="file1`r`nfile2" C:\temp> $foo -split '\r?\n' | Remove-Item
      - Jenk 5y ago
yoyohello13 5y ago
I've recently been thrust into using PowerShell at work too, and it's fine. I still wouldn't choose it, given the option. I get why people like the object orient nature of it, but I also don't think I get much value from it. 9 times out of 10, if I need a shell script, it's just stringing commands together. If I'm doing something complex enough to really benefit from "everything is and object" then why not just use a more capable language like python? There is a trend of people making increasingly complex and expressive shell languages, but I don't really understand what problem they are trying to solve. Maybe what we really need is a less complex shell so people are less tempted to write complex logic with it.
- simion314 5y ago
  I did not use powersehll but recently I was using a CLI program that was outputting in a tabular format but it was not something well defined that I could easily (with my very limited shell experience) parse. Maybe it was the program fault that it did not offer some CSV output format or maybe there is a natural way of handeling it but is hard to google for it.
- rootsofallevil 5y ago
  > If I'm doing something complex enough to really benefit from "everything is and object" then why not just use a more capable language like python? I've seen this line of reasoning mentioned a lot but never justified. A few reasons to stick with Powershell over Python: Team might not be familiar with Python (and the benefits of learning might be outweighed by the learning curve, shallow as it might be) Hard to judge what the cutover point is (namely at what point does a script benefit from being written in Python?) A lot (some?) of stuff out of the box in PS requires libraries in Python, which requires installation, which cannot happen during the script (I think at least, I've not done that much Python)
kukx 5y ago
One thing about PowerShell that annoys me is the verbosity and the use of capital letters in commands. While it is fine for scripts that you write once it feels suboptimal for daily use in a terminal, where I prefer the least strokes possible. Also the slow startup makes me often choose an alternative shell in Windows (CMD,bash).
- JoBrad 5y ago
  Casing doesn’t matter for Powershell commands, but it certainly Improves readability. Aliases certainly help when typing commands, too. I haven’t had startup speed issues with Powershell Core, but when I do, it’s usually because of commands in my profile (which it tells you about).
- partdavid 5y ago
  You don't have to type capitals, and you have aliases just as terse and understandable (?) as standard unix commands: gci, iwr, ri, etc. So you don't have to type them if you don't want to. The But if you forget, it's nice to have them. And for commands at the margin of your memory they're entirely discoverable (including the aliases). It's not necessarily obvious when you start, but it's actually super useful to be able to use and re-use all your skills for selecting and filtering data. Being able to 'get-alias | where definition -like *item' is a great way to discover the terse aliases for file operations, for example.
  - kukx 5y ago
    I know that there are built in workarounds ie default aliases and the case can be omitted. But it creates another set of problems related to documentation and code samples/conventions. The objects passing is great, but it is not enough for me, except for writing scripts. I guess there are ways to make it work fine as an interactive shell, but that is probably an extra customization and in some administrative environments it may not be possible.
- pjmlp 5y ago
  Pascal casing is traditional in PC programming world, since the MS-DOS days, Microsoft just went along with the culture of the platform.

pjmlp 5y ago

It is builds up on top of Xerox PARC ideas regarding REPL and OS integration. UNIX systems could offer similar integration, via IPC mechanisms, KParts and DBus like communication, exposing shared libraries directly into the shell and structured data. Where it fails down is lack of standardization across the landscape, so that everything actually works together.

thibran 5y ago

Did you try out Nushell, what do you think about it in comparison to PowerShell?

pxc 5y ago

Fish has taught me that I should strongly prefer shells with batteries included when it comes to interactivity, and Elvish has beautifully demonstrated how that can be taken even further with things like its built-in navigation mode. PowerShell's big weakness, imo, is that it lacks that emphasis on interactivity OOTB, and configuring it back in often results in astonishingly bad performance. That said, the language is way better than any traditional Unix shell, and the ecosystem of libraries and scripts is insanely comprehensive. Together, these factors make for an absolutely top-notch scripting experience. This is definitely one of the the biggest sources of inspiration for most next-gen Unix shells afaict.

partdavid 5y ago

I've found that as you learn, the verbosity kind of fades away, because you adapt your aliases and patterns to your work habits. The small amount of remaining "extra" verbosity that remains is very worth it, because it gives you more discoverability and more consistent ways of handling data in exchange. I would probably rephrase your statement about object-orientation: I don't think Powershell is particularly object-oriented, but it integrates nicely with object-oriented .NET. What I mean is: when writing extensions to Powershell in Powershell, you may use objects incidentally as containers for structured data, or occasionally to access details in .NET, but you are not creating objects or classes--you're working with functions in a straightforward way, and it's easy to make your functions behave like (take the same options in the same way as) "standard" commands. I switched (completely) a couple of years ago. The main "use case" that is Powershell's sweet spot for me is handling structured data. A lot of my operations have steps like: Do some data-wrangling to calculate a URL and request options for some data repository or integrated system API; Perform a network call or look something up in a big file of structured data; Munge and wrangle that data to extract information or calculate summaries; Perform more network calls based on that data and do further munging and calculating. This is usually discovery-oriented, interactive, ad-hoc lightweight integration, and it's in an environment where I'm doing something with this data (like figuring out a machine list from a couple of CMDBs, cross-referencing that with data from the monitoring system and maybe some lookups for system roles, and then performing commands on them). It's not a great fit for a "real" scripting language because the stuff about processing the data and doing the network calls is intermixed with lots of stuff that the "real" scripting language is not very good at, like interactively discovering what's in the data, invoking a bunch of OS commands and putting things together left-to-right in a pipeline you craft gradually. As your activity matures (you find yourself doing the same thing over and over), you can start factoring your code into reusable units, but not all of it, and Powershell is just super excellent at tasks at this boundary, because it's just fine as a programming language in its own right (much more capable than bash, and with goodies that you reference, like having dependency management) while being at least as good an interactive shell as bash. As a "Unix guy", I favor a lot of Unix-isms so of course I customize my shell heavily. I can do more powerful things in my prompt much more easily than with bash. I like the more familiar bash-style tab-completion than Powershell's, so I use the PSReadLine module settings to enable that. I use vi keys for command-line editing (with remapped cursor motion keys) and getting this done is easier to accomplish than doing so in bash. I don't like some of Powershell core's default aliases (like curl--I want curl to invoke the curl command, and I'll use iwr instead of curl when I want Invoke-WebRequest), so I disable them. I do all of my professional work on MacOS and Linux and Powershell is a good shell on both, and almost all of my experience with Powershell is as a Unix shell. I'm not much of a fan of commitment to the so-called "Unix philosophy", but I do think that Powershell reflects this philosophy better than a typical Unix shell and Unix commands. For example, once you learn how to sort the output of ls according to its standard options, all you've learned is something about the ls command. It doesn't help you in sorting a process list from ps. It also doesn't help you in sorting files by something other than size (-S), mtime (-t), atime (-u sort of), "natural version in the name (what?)" (-v), or alphabetically by extension (-X). According to the "Unix philosophy" what is the ls command even doing parsing and sorting version numbers anyway? In Powershell, it's more natural to let Sort-Object sort things, which it can do by any of the item's fields, not just what the ls author provided an option for; and once you know you can do that, you can do it for processes in just the same way, or AWS instances or anything else. Boom. Unix philosophy. (And if you just like using ls, and piping it to sort, that works fine, too, so no custom is imposed on you). It's kind of beautiful. Our views on what we want out of a shell are always based on the tasks we personally try to accomplish with it, and I don't think the author wants a "better shell" at all, but a better, more scriptable IDE. His "use cases" for the shell are all elementary file management and command invocation and he doesn't really seem clear on which component of his system the shell actually even is. Interestingly, there is a full TUI framework for Powershell and it's pretty cute! I didn't know about it before looking it up after reading this article.

Jenk 5y ago

I still find it grating with how pipes are handled. E.g. git ls-files --exclude-standard -o | For-Each { Remove-Item $_ } Just.. _why_ do I need that For-Each?! (Deliberately not using aliases for clarity)

tyingq 5y ago
As far as I can tell, you don't need it if you're piping the right stuff to Remove-Item C:\temp\foo> dir Directory: C:\temp\foo Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 9/10/2021 1:03 PM 0 thing1 -a---- 9/10/2021 1:03 PM 0 thing2 -a---- 9/10/2021 1:03 PM 0 thing3 C:\temp\foo> dir thing* | Remove-Item C:\temp\foo> dir C:\temp\foo>
- Jenk 5y ago
  dir works because it's actually an alias of Get-ChildItem, which returns a list of objects (DirectoryInfo or FileInfo). My example was specifically a list of paths that are not objects but just strings.
  - tyingq 5y ago
    Okay. How about "echo"? (Aliased to Write-Output, which I assume is strings) C:\temp> dir file3 Directory: C:\temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 9/10/2021 1:03 PM 0 file3 C:\temp> echo "file3" | Remove-Item C:\temp> dir file3 dir : Cannot find path 'C:\temp\file3' because it does not exist. Edit: I see it now. It works with one string, but if I Write-Output "file1`r`nfile2" | Remove-Item it no longer works because it takes the whole string as an object. I'd have to pipe an array of strings rather than cr-lf separated strings. This does work: C:\temp> $foo="file1`r`nfile2" C:\temp> $foo -split '\r?\n' | Remove-Item
    - Jenk 5y ago

yoyohello13 5y ago

I've recently been thrust into using PowerShell at work too, and it's fine. I still wouldn't choose it, given the option. I get why people like the object orient nature of it, but I also don't think I get much value from it. 9 times out of 10, if I need a shell script, it's just stringing commands together. If I'm doing something complex enough to really benefit from "everything is and object" then why not just use a more capable language like python? There is a trend of people making increasingly complex and expressive shell languages, but I don't really understand what problem they are trying to solve. Maybe what we really need is a less complex shell so people are less tempted to write complex logic with it.

simion314 5y ago
I did not use powersehll but recently I was using a CLI program that was outputting in a tabular format but it was not something well defined that I could easily (with my very limited shell experience) parse. Maybe it was the program fault that it did not offer some CSV output format or maybe there is a natural way of handeling it but is hard to google for it.
rootsofallevil 5y ago
> If I'm doing something complex enough to really benefit from "everything is and object" then why not just use a more capable language like python? I've seen this line of reasoning mentioned a lot but never justified. A few reasons to stick with Powershell over Python: Team might not be familiar with Python (and the benefits of learning might be outweighed by the learning curve, shallow as it might be) Hard to judge what the cutover point is (namely at what point does a script benefit from being written in Python?) A lot (some?) of stuff out of the box in PS requires libraries in Python, which requires installation, which cannot happen during the script (I think at least, I've not done that much Python)

kukx 5y ago

One thing about PowerShell that annoys me is the verbosity and the use of capital letters in commands. While it is fine for scripts that you write once it feels suboptimal for daily use in a terminal, where I prefer the least strokes possible. Also the slow startup makes me often choose an alternative shell in Windows (CMD,bash).

JoBrad 5y ago
Casing doesn’t matter for Powershell commands, but it certainly Improves readability. Aliases certainly help when typing commands, too. I haven’t had startup speed issues with Powershell Core, but when I do, it’s usually because of commands in my profile (which it tells you about).
partdavid 5y ago
You don't have to type capitals, and you have aliases just as terse and understandable (?) as standard unix commands: gci, iwr, ri, etc. So you don't have to type them if you don't want to. The But if you forget, it's nice to have them. And for commands at the margin of your memory they're entirely discoverable (including the aliases). It's not necessarily obvious when you start, but it's actually super useful to be able to use and re-use all your skills for selecting and filtering data. Being able to 'get-alias | where definition -like *item' is a great way to discover the terse aliases for file operations, for example.
- kukx 5y ago
  I know that there are built in workarounds ie default aliases and the case can be omitted. But it creates another set of problems related to documentation and code samples/conventions. The objects passing is great, but it is not enough for me, except for writing scripts. I guess there are ways to make it work fine as an interactive shell, but that is probably an extra customization and in some administrative environments it may not be possible.
pjmlp 5y ago
Pascal casing is traditional in PC programming world, since the MS-DOS days, Microsoft just went along with the culture of the platform.