Hacker News Reader

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.

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.

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.

> 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)

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).

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).

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.

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.

Pascal casing is traditional in PC programming world, since the MS-DOS days, Microsoft just went along with the culture of the platform.

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.

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

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)

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>

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.

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

Yeah, another one I haven't worked out yet is opening mulitple files from shell. So far this is what I can come up with:

    @(Get-ChildItem *.ts | foreach { $_.Name } | Join-String -Separator ' ') | foreach { nvim -- $_ }

But even that abomnination doesn't quite work.

I suspect that this is sufficient for your needs:

    nvim -- (( dir *.ts ).Name -join ' ')

I don't have nvim, but the equivalent worked for me with "code" (VS Code).

That does indeed work but it's quite different from piping. But thanks that has increased my productivity!

I use fzf a lot so I'll be adapting it for that too :)

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.

Not only .NET, in case you haven't bumped into it, it also does COM, and any dynamic library as well.