Hacker News Reader

I've said this on here many times, but PS only works well with small files. Your examples with even 50 MB files absolutely crawl when Unix is blazing. We're talking 10 minutes vs like 3 seconds. PS code is nice once you get the hang of it, but I've finally abandoned it for most tasks after a few years due to the performance issues. It turns out converting everything to objects is slow slow.

This kind of thing could be done in Unix as well.

In FreeBSD, libxo[0] is integrated into a lot of it's utilities, allowing this same type of power.

For example:

  ps aux --libxo json

Or:

  ps aux --libxo xml

At this point you still have plain text, but it now has a well-defined structure that can be interpreted by other utilities. With JSON output you can use a tool like `jq` to slice and dice the data. With XML output you could run it through an XSLT to transform it into whatever you want - this definitely moves outside the realm of simple though.

This is definitely not on the same level as what PowerShell does, but it shows how something similar could exist in the Unix world.

[0] https://www.freebsd.org/cgi/man.cgi?query=libxo&sektion=3

The problem with PowerShell (aside from its verbosity) is that you essentially have to relearn the name of every command and every option, throwing all your existing shell knowledge out.

I earnestly used PS as my main shell for a number of years, but this learning curve was just too steep. Once WSL turned up I jumped ship.

I get it, and I respect the effort to clean up shell and create something coherent, but the commands and casing are really overdone and feel like old IBM mainframe commands that require looking up a physical binder to use effectively. Start by replacing the commands with simple verbs like "walk", "filter" and "convert" and give them some default positional args.

I think a proper shell should still have a few shortcuts that break coherence for convenience, as long as there also is a long form for script readability.

> Start by replacing the commands with simple verbs like "walk", "filter" and "convert" and give them some default positional args

PowerShell commands (more accurately, cmdlets[0]) have a fixed Verb-Noun syntax. Get-ChildItem, Invoke-WebRequest, etc etc.

[0]: https://docs.microsoft.com/en-us/powershell/scripting/powers...

Right, and that verb-noun convention reminds me of https://www.techtarget.com/whatis/reference/Common-AS-400-co...

...and it's not good. At least AS/400 commands had terseness to them. Those powershell commands are ok-ish for scripting but much too long for interactive shell sessions where you need to "explore the space".

> much too long for interactive shell sessions

There exist aliases[0] for the most commonly-used cmdlets.

[0]: https://docs.microsoft.com/en-us/powershell/scripting/learn/...

I tend to agree. After working with data outputs from a variety of Linux sources for years I find the PS output is much more standardized -- or at least PS handles string outputs in a much more standardized way. I love the Select-String ... approach to field display. Making and outputting tables in PS is much slicker than the same magic on Linux. Ugly is a matter of opinion, but the real magic of PS is never having to drop characters or spaces to munge text into a column.

"It's very nice indeed, but PowerShell pipelines are at another level of beauty"

What?!??

"PowerShell is weird"

Yes, totally agree with that.

Sorrt, I can't tell if this is sarcasm.

Is there something I'm missing? Even the above examples look awful to me

It's not sarcasm: I actually like PS because it builds on the concept of data pipelines, to turn them into something more object orientend.

The only thing similar in the Linux world is using sqlite as the target of pipe to do some data processing, like on a ps output, find the name of the process using the most RAM.

Structurally, the language seems both Perl inspired and something a bit like of an hybrid of LISP (for the object) and SQL (for how most structures are manipulated)

In the FreeBSD world, we have libxo[0] which allows utilities to produce structured output.

To use your example, taking the output of ps and finding the process using the most RAM, you could do something like this:

  $ ps aux --libxo json|jq '."process-information"."process" | sort_by((.rss)|tonumber) | .[-1]'
  {
    "user": "root",
    "pid": "2372",
    "percent-cpu": "0.0",
    "percent-memory": "11.4",
    "virtual-size": "2149236",
    "rss": "1906584",
    "terminal-name": "- ",
    "state": "SC",
    "start-time": "21May22",
    "cpu-time": "1307:09.11",
    "command": "bhyve: postgresql (bhyve)"
  }

It's not pretty, but it does let you get structured data out of most of the base system utilities to make the slicing and dicing easier.

[0] https://www.freebsd.org/cgi/man.cgi?query=libxo&sektion=3

> I actually like PS because it builds on the concept of data pipelines, to turn them into something more object orientend.

It certainly is an interesting idea. I think the .Net dependency makes it more heavyweight than it might have otherwise been. I wonder if anyone at Microsoft has ever thought about porting it from C# to C++ (I suppose using COM/WinRT).

I think a big deficiency with pipes is they don’t come with any protocol for out-of-band content negotiation. Someone could add an IOCTL you could call on a write pipe (or Unix domain socket) to advertise supported MIME types, and blocks waiting for the other end to select one. The read end can call another IOCTL to get supported MIME types, and then a third to indicate its choice. If the read end doesn’t support this protocol, you could make it the first IOCTL is unblocked by the first read()/recvmsg() call on the read end, so this protocol still works even if the other end doesn’t support content negotiation. Utilities could default to producing text/plain, but generate application/json instead if the other end supports it.