3 ms·

Because the UNIX terminal model is mostly "good enough" (and with a recent incarnation like zsh plus Fish-style autosuggestion-plugin the user experience is ver

Because the UNIX terminal model is mostly "good enough" (and with a recent incarnation like zsh plus Fish-style autosuggestion-plugin the user experience is very different from a plain VT100 terminal from the 70's). PowerShell isn't such a big revolution in user experience that it justifies switching IMHO (and FWIW I don't agree that objects are better than a plain text stream, at least not when the whole thing stops in the terminal - it would probably be different if every Windows application - including all UI applications - would expose their internals as "PowerShell-scriptable objects", then we could probably get an actual productivity jump by glueing small, specialised UI apps together - this was a central idea in the last days of the Amiga which didn't make the jump to other platforms before its demise). Same for the concept of a hierarchical filesystem. Sure, there may be better ideas floating around, but when confronted with reality they are usually not so much better than the "good enough" status quo that current operating systems have arrived at. TL;DR: long-term incremental progress usually beats revolutionary ideas that are poorly executed.

dale_glass 3y ago
Powershell is immensely better. It takes what Unix promises and delivers it, without all the pain. Eg: C:\Windows> (Get-AuthenticodeSignature .\explorer.exe).SignerCertificate.Subject CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US C:\Windows> Think of doing that in classic Unix. How does that command output a tree shaped structure, where items have sub-items? How do you parse that? How do you make sure that your parsing doesn't get confused by the presence of an unexpected = or :? How do you deal with that maybe some certificates have extensions? Oh, we actually have commands that do that sort of thing, GPG does it. $ gpg --with-colons --list-keys \ --with-fingerprint --with-fingerprint wk@gnupg.org pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC: fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013: uid:f::::::::Werner Koch <wk@g10code.com>: uid:f::::::::Werner Koch <wk@gnupg.org>: sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e: fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1: sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc: fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4: And it's awful. It's colon separated, so I'm not sure what happens if somebody puts one in their name. And you have to count fields. And it's completely non-extensible, good luck inserting an extra column. But hey, you can parse that with AWK.
- flohofwoe 3y ago
  Point taken, but there's nothing prohibiting commands from outputting their data in a different text format that's better suited for tree-like data (like JSON), and another set of minimal commands which processes JSON-formatted data - easy extensibility by the user is also part of the "UNIX philosophy". That's also the point where I'd reach for Python or Deno/TS to write such command line tools, because both Bash and C are not really well suited for text processing - and neither are the traditional UNIX tools like sed or awk IMHO.
  - dale_glass 3y ago
    JSON would be better, true, but PowerShell actually has objects, so dates are actually dates and not just a string containing a date. So you can actually do timezone conversions and calculations on what you get directly, rather than having to feed the date string into a parser. But yeah, JSON would be a good start. But for some reason there seems to be little interest even in that. Wouldn't it be nice to have `df --json` or `mount --json`? And that makes me sad, because the system could be so much better if it moved forward a bit instead of being stuck in the 80s.
    - AnimalMuppet 3y ago
      Honest question: How do you do discovery on PowerShell objects? That is, with the Unix approach, when I'm trying to do something ad hoc I can do one step of a pipe, read the results on the terminal, see what the format is, and figure out how I have to set up the next step of the pipe. How do I do that with PowerShell?
      - dale_glass 3y ago
        Pipe it through Format-List: C:\Windows> Get-Item .\explorer.exe | Format-List This gives you the generally useful view of what Get-Item returned. You can ask to see everything with: C:\Windows> Get-Item .\explorer.exe | Format-List -Property * Tab completion also completes these. Some of what you get can be subdivided further if you look, eg: C:\Windows> (Get-Item .\explorer.exe).VersionInfo.FileVersionRaw | Format-List -Property *

dale_glass 3y ago

Powershell is immensely better. It takes what Unix promises and delivers it, without all the pain. Eg: C:\Windows> (Get-AuthenticodeSignature .\explorer.exe).SignerCertificate.Subject CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US C:\Windows> Think of doing that in classic Unix. How does that command output a tree shaped structure, where items have sub-items? How do you parse that? How do you make sure that your parsing doesn't get confused by the presence of an unexpected = or :? How do you deal with that maybe some certificates have extensions? Oh, we actually have commands that do that sort of thing, GPG does it. $ gpg --with-colons --list-keys \ --with-fingerprint --with-fingerprint wk@gnupg.org pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC: fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013: uid:f::::::::Werner Koch <wk@g10code.com>: uid:f::::::::Werner Koch <wk@gnupg.org>: sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e: fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1: sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc: fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4: And it's awful. It's colon separated, so I'm not sure what happens if somebody puts one in their name. And you have to count fields. And it's completely non-extensible, good luck inserting an extra column. But hey, you can parse that with AWK.

flohofwoe 3y ago
Point taken, but there's nothing prohibiting commands from outputting their data in a different text format that's better suited for tree-like data (like JSON), and another set of minimal commands which processes JSON-formatted data - easy extensibility by the user is also part of the "UNIX philosophy". That's also the point where I'd reach for Python or Deno/TS to write such command line tools, because both Bash and C are not really well suited for text processing - and neither are the traditional UNIX tools like sed or awk IMHO.
- dale_glass 3y ago
  JSON would be better, true, but PowerShell actually has objects, so dates are actually dates and not just a string containing a date. So you can actually do timezone conversions and calculations on what you get directly, rather than having to feed the date string into a parser. But yeah, JSON would be a good start. But for some reason there seems to be little interest even in that. Wouldn't it be nice to have `df --json` or `mount --json`? And that makes me sad, because the system could be so much better if it moved forward a bit instead of being stuck in the 80s.
  - AnimalMuppet 3y ago
    Honest question: How do you do discovery on PowerShell objects? That is, with the Unix approach, when I'm trying to do something ad hoc I can do one step of a pipe, read the results on the terminal, see what the format is, and figure out how I have to set up the next step of the pipe. How do I do that with PowerShell?
    - dale_glass 3y ago
      Pipe it through Format-List: C:\Windows> Get-Item .\explorer.exe | Format-List This gives you the generally useful view of what Get-Item returned. You can ask to see everything with: C:\Windows> Get-Item .\explorer.exe | Format-List -Property * Tab completion also completes these. Some of what you get can be subdivided further if you look, eg: C:\Windows> (Get-Item .\explorer.exe).VersionInfo.FileVersionRaw | Format-List -Property *