7 ms·

It's very nice indeed, but PowerShell pipelines are at another level of beauty: think what you could do if instead of just STDOUT (and STDERR to be fair) you ha

by csdvrx 4y ago

It's very nice indeed, but PowerShell pipelines are at another level of beauty: think what you could do if instead of just STDOUT (and STDERR to be fair) you had data structures with names On Windows try for the fun it: Get-ChildItem -Path HKLM:\SYSTEM\ControlSet001\Services\DeviceAssociationService\State\Store\ | Select-String -Pattern Bluetooth Now look at how it parallelize the request by default, and how it returned you several columns of data per line. Want a regex? Get-ChildItem -Path HKLM:\SYSTEM\ControlSet001\Services\DeviceAssociationService\State\Store\ | Select-String -Pattern Bluetooth | ForEach-Object { $_ -replace 'HK.*-','' -replace ':', ''} Want a CSV? Add "| ConvertTo-Csv" Let's do another, to filter only devices (a named property) Get-PnpDevice -Class 'Bluetooth' -PresentOnly | Where-Object HardwareID -match 'DEV_' | Get-PnpDeviceProperty | ConvertTo-Csv Now I'm learning how to do better things like lambdas on the pipeline PowerShell is weird the first time, but it's so well made it'll give you hours and hours of fun :)

deleted 4y ago
[deleted]
Tijdreiziger 4y ago
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.
xthrowawayxx 4y ago
Sorrt, I can't tell if this is sarcasm. Is there something I'm missing? Even the above examples look awful to me
- csdvrx 4y ago
  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)
  - Mister_Snuggles 4y ago
    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 https://www.freebsd.org/cgi/man.cgi?query=libxo&sektion=3
  - skissane 4y ago
    > 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.
LoveGracePeace 4y ago
"It's very nice indeed, but PowerShell pipelines are at another level of beauty" What?!?? "PowerShell is weird" Yes, totally agree with that.
7thaccount 4y ago
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.
speed_spread 4y ago
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.
- delta_p_delta_x 4y ago
  > 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/powershell-commands?view=powershell-7.2 https://docs.microsoft.com/en-us/powershell/scripting/powers...
  - speed_spread 4y ago
    Right, and that verb-noun convention reminds me of https://www.techtarget.com/whatis/reference/Common-AS-400-commands 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".
    - delta_p_delta_x 4y ago
      > 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/compatibility-aliases?view=powershell-7.2 https://docs.microsoft.com/en-us/powershell/scripting/learn/...
Mister_Snuggles 4y ago
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 https://www.freebsd.org/cgi/man.cgi?query=libxo&sektion=3
iamwpj 4y ago
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.

by csdvrx 4y ago

deleted 4y ago

[deleted]

Tijdreiziger 4y ago

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.

xthrowawayxx 4y ago

Sorrt, I can't tell if this is sarcasm. Is there something I'm missing? Even the above examples look awful to me

csdvrx 4y ago
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)
- Mister_Snuggles 4y ago
  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 https://www.freebsd.org/cgi/man.cgi?query=libxo&sektion=3
- skissane 4y ago
  > 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.

LoveGracePeace 4y ago

"It's very nice indeed, but PowerShell pipelines are at another level of beauty" What?!?? "PowerShell is weird" Yes, totally agree with that.

7thaccount 4y ago

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.

speed_spread 4y ago

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.

delta_p_delta_x 4y ago
> 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/powershell-commands?view=powershell-7.2 https://docs.microsoft.com/en-us/powershell/scripting/powers...
- speed_spread 4y ago
  Right, and that verb-noun convention reminds me of https://www.techtarget.com/whatis/reference/Common-AS-400-commands 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".
  - delta_p_delta_x 4y ago
    > 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/compatibility-aliases?view=powershell-7.2 https://docs.microsoft.com/en-us/powershell/scripting/learn/...

Mister_Snuggles 4y ago

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 https://www.freebsd.org/cgi/man.cgi?query=libxo&sektion=3

iamwpj 4y ago

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.