4 ms·

Powershell improves on Unix commands being based on text streams, and makes them based on objects. Which means you're pretty much never extracting stuff with cu

Powershell improves on Unix commands being based on text streams, and makes them based on objects. Which means you're pretty much never extracting stuff with cut and awk, and instead can just get whatever field you want. Eg: C:\Windows> Get-AuthenticodeSignature .\explorer.exe Directory: C:\Windows SignerCertificate Status StatusMessage Path ----------------- ------ ------------- ---- BBD2C438000344F439BFDFE5ABAC3223357CD67F Valid Signature verified. explorer.exe C:\Windows> (Get-AuthenticodeSignature .\explorer.exe).SignerCertificate Thumbprint Subject EnhancedKeyUsageList ---------- ------- -------------------- BBD2C438000344F439BFDFE5ABAC3223357CD67F CN=Microsoft Window… {Windows System Component Verification, Code Signing} C:\Windows> (Get-AuthenticodeSignature .\explorer.exe).SignerCertificate.Subject CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US C:\Windows> This of course works with pipes: C:\Windows> Get-ChildItem . | Where-Object { $_.Length -gt 1000000 } | Sort-Object Length Directory: C:\Windows Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 8/11/2021 1:56 AM 1075712 HelpPane.exe -a--- 1/15/2018 12:40 PM 2856800 RtlExUpd.dll -a--- 4/25/2022 1:17 PM 5122632 explorer.exe Isn't that awesome? One of the nice things about it is that you can add stuff easily. You don't have to worry that every script that parses the output of your command will now break because you added an extra column or added extra functionality.

majkinetor 5y ago
Yes it is. Its not awesome however to write Where-Object and Foreach-Object instead ? and %. It really turns one down. I can understand fanboyism for not using other aliases but those 2 are special and not using them brings the wrong picture about the pwsh.
paskozdilar 5y ago
> Powershell improves on Unix commands being based on text streams, and makes them based on objects I assume this means that PowerShell is deeply integrated with the .NET ecosystem? I don't like .NET very much, so that's a downside for me. One of the reasons I use Bash is the decades-old ecosystem of various utilities people have written. Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-stream processing pipelines like Bash, or is it .NET objects only?
- majkinetor 5y ago
  > I don't like .NET very much, so that's a downside for me. LOL. So arbitrary... do you like java vm or python? > Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-stream processing pipelines like Bash, or is it .NET objects only? Sure. Even better, it can convert wall of text into array of lines on the fly :) You should forget about parsing text in shell though. Because it sux and we know better now. Parsing text in pwsh is once-a-year thing.
  - deleted 5y ago
    [deleted]
  - paskozdilar 5y ago
    Yeah? Well, you know, that's just, like, uh, your opinion, man.
    - majkinetor 5y ago
      Yours is not even opinion. You need to put some logic behind it man :) As for me, I will keep my Decade-And-More-Old-And-Still-Shiny-Shell-With-Objects-And-Stuff to myself :)
      - paskozdilar 5y ago
        I don't think I need to "put some logic behind" not liking .NET, same as I dont need to put some logic behind not liking Java. It just sux and we know better now :) Also good luck with your emacs pinky. :) :) :) :D :D :D :) :) :^)
inkyoto 5y ago
> Isn't that awesome? It depends. In a world where commands produce, expect and consume well defined and highly structured data streams, it is actually great. It works well in Windows but only because scripting as the concept is relatively new to the Windows world. In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the output of a command (for any reason, really) as the UNIX style is precisely this: «cobble things together, use a sledgehammer to make everything work and move on. If it ain't broken then don't fix it». This is why running the output through a «sed» and searching for stable string patterns to cut interesting parts out and then (optionally) running them through cut/awk/et al is the Swiss army knife. Life has become somewhat easier recently with the advent and more widespread use of JSON, YAML (and to a certain extent XML before) as we now have jq, yq, dasel, mlr (Miller), xmlto etc – to capture, for instance, the JSON formatted output and do something with it just in the same way it is possible in PowerShell whilst also retaining the extensibility (see below) without having to rely on the availability of the source code of the producing utility/app. > One of the nice things about it is that you can add stuff easily. You don't have to worry that every script that parses the output of your command will now break because you added an extra column or added extra functionality. You can only add stuff easily if you control (own) the producer of the data stream. If the producer is a third party provided script/app you don't have the source code for, I believe you still have the same breakage problem, however PowerShell experts might want to chime in and correct me.
- dale_glass 5y ago
  > In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the output of a command Where would they come from? > (for any reason, really) as the UNIX style is precisely this: «cobble things together, use a sledgehammer to make everything work and move on. If it ain't broken then don't fix it». This is why running the output through a «sed» and searching for stable string patterns to cut interesting parts out and then (optionally) running them through cut/awk/et al is the Swiss army knife. If you're doing that a lot, the code tends to be fragile. If you use cut for instance, it breaks the second the data you're working it changes. Program decided column needs to be 5 characters wider? Now the stuff you're looking for is not there anymore. That's how you end up with "ifconfig is old, everyone switch to ip now". At some point a program's output may be parsed by so much stuff that any change risks breaking something, and it forces it to remain static for eternity. > You can only add stuff easily if you control (own) the producer of the data stream. If the producer is a third party provided script/app you don't have the source code for, I believe you still have the same breakage problem, however PowerShell experts might want to chime in and correct me. No, my point is that the producer is free to improve without risking the consumers. If your command that produced IPv4 addresses adds support for IPv6, it doesn't suddenly break every script that relies on precise lengths, line numbers and columns. You can also take somebody else's returned data and add extra stuff to it if you want to, just like you could take a bunch of JSON and modify it.

majkinetor 5y ago

Yes it is. Its not awesome however to write Where-Object and Foreach-Object instead ? and %. It really turns one down. I can understand fanboyism for not using other aliases but those 2 are special and not using them brings the wrong picture about the pwsh.

paskozdilar 5y ago

> Powershell improves on Unix commands being based on text streams, and makes them based on objects I assume this means that PowerShell is deeply integrated with the .NET ecosystem? I don't like .NET very much, so that's a downside for me. One of the reasons I use Bash is the decades-old ecosystem of various utilities people have written. Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-stream processing pipelines like Bash, or is it .NET objects only?

majkinetor 5y ago
> I don't like .NET very much, so that's a downside for me. LOL. So arbitrary... do you like java vm or python? > Can PowerShell use the same CLI utilities as Bash, and do the plain-old-text-stream processing pipelines like Bash, or is it .NET objects only? Sure. Even better, it can convert wall of text into array of lines on the fly :) You should forget about parsing text in shell though. Because it sux and we know better now. Parsing text in pwsh is once-a-year thing.
- deleted 5y ago
  [deleted]
- paskozdilar 5y ago
  Yeah? Well, you know, that's just, like, uh, your opinion, man.
  - majkinetor 5y ago
    Yours is not even opinion. You need to put some logic behind it man :) As for me, I will keep my Decade-And-More-Old-And-Still-Shiny-Shell-With-Objects-And-Stuff to myself :)
    - paskozdilar 5y ago
      I don't think I need to "put some logic behind" not liking .NET, same as I dont need to put some logic behind not liking Java. It just sux and we know better now :) Also good luck with your emacs pinky. :) :) :) :D :D :D :) :) :^)

inkyoto 5y ago

> Isn't that awesome? It depends. In a world where commands produce, expect and consume well defined and highly structured data streams, it is actually great. It works well in Windows but only because scripting as the concept is relatively new to the Windows world. In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the output of a command (for any reason, really) as the UNIX style is precisely this: «cobble things together, use a sledgehammer to make everything work and move on. If it ain't broken then don't fix it». This is why running the output through a «sed» and searching for stable string patterns to cut interesting parts out and then (optionally) running them through cut/awk/et al is the Swiss army knife. Life has become somewhat easier recently with the advent and more widespread use of JSON, YAML (and to a certain extent XML before) as we now have jq, yq, dasel, mlr (Miller), xmlto etc – to capture, for instance, the JSON formatted output and do something with it just in the same way it is possible in PowerShell whilst also retaining the extensibility (see below) without having to rely on the availability of the source code of the producing utility/app. > One of the nice things about it is that you can add stuff easily. You don't have to worry that every script that parses the output of your command will now break because you added an extra column or added extra functionality. You can only add stuff easily if you control (own) the producer of the data stream. If the producer is a third party provided script/app you don't have the source code for, I believe you still have the same breakage problem, however PowerShell experts might want to chime in and correct me.

dale_glass 5y ago
> In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the output of a command Where would they come from? > (for any reason, really) as the UNIX style is precisely this: «cobble things together, use a sledgehammer to make everything work and move on. If it ain't broken then don't fix it». This is why running the output through a «sed» and searching for stable string patterns to cut interesting parts out and then (optionally) running them through cut/awk/et al is the Swiss army knife. If you're doing that a lot, the code tends to be fragile. If you use cut for instance, it breaks the second the data you're working it changes. Program decided column needs to be 5 characters wider? Now the stuff you're looking for is not there anymore. That's how you end up with "ifconfig is old, everyone switch to ip now". At some point a program's output may be parsed by so much stuff that any change risks breaking something, and it forces it to remain static for eternity. > You can only add stuff easily if you control (own) the producer of the data stream. If the producer is a third party provided script/app you don't have the source code for, I believe you still have the same breakage problem, however PowerShell experts might want to chime in and correct me. No, my point is that the producer is free to improve without risking the consumers. If your command that produced IPv4 addresses adds support for IPv6, it doesn't suddenly break every script that relies on precise lengths, line numbers and columns. You can also take somebody else's returned data and add extra stuff to it if you want to, just like you could take a bunch of JSON and modify it.