Yes, if it was as object based as it claims, Get-WmiObject would subtract WmiObject from Get. Instead it is like having all the clutchy drawbacks from being object based without reaping any of the potential bemefits.
If you want anything that actually is object based, just use xon.sh - sane and familiar syntax with insane amounts of power just like that
It’s from the beginning meant to be fully scripted though. You’re not supposed to be putting in these commands manually, it’s meant to be used in an environment where the 5-50 commands you or your company needs constantly have aliases and script files defined and on PATH.
Don’t you think immediately getting the property you’re interested in from an object is easier and more readable than first grepping some output to get the line you want and then removing the leading and trailing garbage on that line manually?
I thing PS scripting would be much more fun if the words weren’t so annoyingly long.
first grepping some output to get the line you want and then removing the leading and trailing garbage on that line manually
That’s not what we do, though. Give me a more concrete example, and I’ll let you know how I would expect to do it in a nix environment. I’d be curious to compare. Since I have zero experience with powershell, I am not really sure what to expect. The couple times I’ve glanced at a powershell script it looked awful, but I could be falling into Paul Graham’s blub paradox there. OK, I don’t think so, but maybe.
I think I misunderstood you, when you said “manually”, to mean as a human intervention in the process. What you’re showing here is an extra processing step, but I wouldn’t call that manual. Just want to clear that up, but I’m still down to play.
Instead of three greps, you could use one sed or awk. I don’t think there’s anything particularly wizardly about awk, and it would be a lot less cryptic, to me, than this chain of greps.
But a much better idea would be to use sensors -j to get json output, intended for machine reading, and pass that to jq. Since I don’t have the same sensors output as you, I’m not sure exactly what that would be, but I am guessing probably something like:
What you’re showing here is an extra processing step, but I wouldn’t call that manual.
Yes, it’s not manual by the dictionary definition, but it is an extra step. This is another meaning of manual in my particular bubble [Edit: that I didn’t think to specify].
But a much better idea would be to use sensors -j to get json output, intended for machine reading, and pass that to jq.
This is my initial point, exactly. Dealing with objects is way easier than using the ‘default’ line-wise processing. Only Powershell made that the default, while in Linux you need to hope that utilities have an option to toggle it on – and then also have jq installed to process the objects.
I look forward to seeing how you would do this in PS. As I said previously, I don’t know it at all, so I’m not sure what you’re comparing this to.
[Edit, since I forgot to answer your main point:] I don’t program in PS. I don’t like the verbosity. But I do think MS has a point in pushing objects as the prime unit in processing instead of lines.
Get-Disk would have sufficed here, no real need to use WMI here. That said, you would still need to filter USB device and select properties you want to retrieve.
And unrelated, but if WMI class needs to be queried, Get-CimInstance is the preferred method instead of Get-WmiObject for quite some time.
Look what they need to mimic a fraction of our power.
I’ve always been particularly revolted by powershell syntax and utilities
Yes, if it was as object based as it claims, Get-WmiObject would subtract WmiObject from Get. Instead it is like having all the clutchy drawbacks from being object based without reaping any of the potential bemefits.
If you want anything that actually is object based, just use xon.sh - sane and familiar syntax with insane amounts of power just like that
Or nushell.
Is this a joke
It’s from the beginning meant to be fully scripted though. You’re not supposed to be putting in these commands manually, it’s meant to be used in an environment where the 5-50 commands you or your company needs constantly have aliases and script files defined and on PATH.
I mean, that’s great, I hate scripting in powershell too though lol.
Fair, as do I honestly. 😅
Text Based OS > Object Based OS
Everything that is wrong with PowerShell in my opinion is driven by the Object Oriented nature of Windows as an OS.
Since everything in Linux is text, grep is king.
Don’t you think immediately getting the property you’re interested in from an object is easier and more readable than first grepping some output to get the line you want and then removing the leading and trailing garbage on that line manually?
I thing PS scripting would be much more fun if the words weren’t so annoyingly long.
That’s not what we do, though. Give me a more concrete example, and I’ll let you know how I would expect to do it in a nix environment. I’d be curious to compare. Since I have zero experience with powershell, I am not really sure what to expect. The couple times I’ve glanced at a powershell script it looked awful, but I could be falling into Paul Graham’s blub paradox there. OK, I don’t think so, but maybe.
For instance: Get the temperature of the “Composite” sensor from this output:
$ sensors k10temp-pci-00c3 Adapter: PCI adapter Tctl: +37.1°C BAT1-acpi-0 Adapter: ACPI interface in0: 16.07 V curr1: 1.80 A amdgpu-pci-0500 Adapter: PCI adapter vddgfx: 1.46 V vddnb: 918.00 mV edge: +35.0°C slowPPT: 1000.00 uW nvme-pci-0200 Adapter: PCI adapter Composite: +28.9°C (low = -5.2°C, high = +79.8°C) (crit = +84.8°C) acpitz-acpi-0 Adapter: ACPI interface temp1: +37.0°C (crit = +120.0°C)Without a cryptic awk incantation that only wizards can understand, that would be:
sensors | grep Composite | grep -Po 'Composite:.*?C' | grep -Eo '[[:digit:]]{1,2}\.[[:digit:]]'I think I misunderstood you, when you said “manually”, to mean as a human intervention in the process. What you’re showing here is an extra processing step, but I wouldn’t call that manual. Just want to clear that up, but I’m still down to play.
Instead of three greps, you could use one sed or awk. I don’t think there’s anything particularly wizardly about awk, and it would be a lot less cryptic, to me, than this chain of greps.
But a much better idea would be to use
sensors -jto get json output, intended for machine reading, and pass that tojq. Since I don’t have the same sensors output as you, I’m not sure exactly what that would be, but I am guessing probably something like:sensors -j | jq '."nvme-pci-0200".Composite.composite_input'I look forward to seeing how you would do this in PS. As I said previously, I don’t know it at all, so I’m not sure what you’re comparing this to.
Yes, it’s not manual by the dictionary definition, but it is an extra step. This is another meaning of manual in my particular bubble [Edit: that I didn’t think to specify].
This is my initial point, exactly. Dealing with objects is way easier than using the ‘default’ line-wise processing. Only Powershell made that the default, while in Linux you need to hope that utilities have an option to toggle it on – and then also have
jqinstalled to process the objects.[Edit, since I forgot to answer your main point:] I don’t program in PS. I don’t like the verbosity. But I do think MS has a point in pushing objects as the prime unit in processing instead of lines.
It would be better if they leaned into it. Instead it is object based…. Until it isn’t because then it’s clunky.
Also lots of command line tools have a flag to output json, and then you can do everything powershell can
And for those that don’t you have JC
Get-Disk would have sufficed here, no real need to use WMI here. That said, you would still need to filter USB device and select properties you want to retrieve.
And unrelated, but if WMI class needs to be queried, Get-CimInstance is the preferred method instead of Get-WmiObject for quite some time.