[smoldesu]

Yeah. Reading the 3-pipe solution in bash versus 4-pipe solution in Powershell felt like it was verging on parody. Yes, these object-oriented features are nice - but they're something of a self-imposed problem on an OS that's designed like a database. Even the tools we use to parse JSON in bash aren't all that bad, if you can keep yourself grounded in the world of text processing.

I'm glad that the OP has a workflow that they like, but I'm not really convinced the grass is greener on the other side. I've used a lot of shells, Powershell doesn't really wow me that much anymore.

[kaba0]

Nah, passing text around is not a good thing, you can’t even write a properly maintainable script that queries the temperature of your hardware or whatever property you are interested in, these will be one-off hacks, breaking even from a change in locale.

[emodendroket]

If the long command names bother you so much most have short aliases, but it's worth remembering that the short ones are cryptic and not that instructive if you're not already initiated.

[smoldesu]

It's not that bad. I'm mostly balking at the idea of `ConvertFrom-Json | ForEach-Object { $_.name }` being any easier to remember than `jq '.[].name' -r`. Both examples seem to "convert" text to JSON with a parser, it's like arguing over the difference between awk and catting into grep. Neither really seem more advantageous than the other.

[doorhammer]

How I'd normally write that command in PS:

`$someJsonText | convertfrom-json | % name`

the `| % [property name]` is shorthand for pulling out some root level property on an object in the pipeline

(just for reference; not really trying to prove any point)

What I personally like about PS in this case is that the syntax of the operation feels very consistent with the rest of powershell, but that's not a dig against jq (I use it a lot when I'm on macos); just my subjective impression, and not an objective claim of quality.

[shortrounddev]

The point is not about being easy to remember (powershell commands and their args can be autocompleted with tab so memorizing them isn't really important). It's about powershell being the object manipulation environment instead of a 3rd party tool like jq. This makes it easier to do stuff with your data with a .Net powered runtime rather than having to manipulate strings using tools with their own built in languages

[emodendroket]

I find the former much more self-explanatory than the latter but, for instance, can't ForEach-Object be written as for?

[cyberbanjo]

I'm still a PowerShell novice, but I believe ForEach-Object and ForEach are subtly different, and PowerShell has classic For(Init; Condition; Increment) loops also but it's even more different than those two.

[deafpolygon]

ForEach-Object and ForEach are the same thing.

Get-Help ForEach-Object

...

ALIASES foreach %

[cyberbanjo]

I have seen that, and that's partially why it seemed so confusing to me but at least one difference is

  The ForEach-Object cmdlet works much like the Foreach statement, except that you can't pipe input to a Foreach statement. For more information about the Foreach statement, see about_Foreach.

https://learn.microsoft.com/en-us/powershell/module/microsof...

And another appears to be performance

  PS /home/me> $time = (Measure-Command {
  >>     1..1E4 | ForEach-Object {
  >>         $_
  >>     }
  >> }).TotalMilliseconds
  PS /home/me>  [pscustomobject]@{
  >>     Type = 'ForEach-Object'
  >>     Time_ms = $Time
  >>  }
  Type           Time_ms
  ----           -------
  ForEach-Object 144.558



  PS /home/me> $Time = (Measure-Command {
  >>     ForEach ($i in (1..1E4)) {
  >>         $i
  >>     }
  >> }).TotalMilliseconds
  PS /home/me>   [pscustomobject]@{
  >>     Type = 'ForEach_Statement'
  >>     Time_ms = $Time
  >>  }
  Type              Time_ms
  ----              -------
  ForEach_Statement  17.621

https://devblogs.microsoft.com/scripting/getting-to-know-for...