3 ms·

I agree, PowerShell does the same thing better. And I'm disappointed that things have stagnated so much. I mean, cool, a commandline is an useful concept that

I agree, PowerShell does the same thing better. And I'm disappointed that things have stagnated so much. I mean, cool, a commandline is an useful concept that sometimes fits a given task excellently well. But why in the hell are we still emulating a VT100? How is a modern Linux console sticking to a 50 year old level of functionality? And why are we scripting in something as painful as Bash?

bluetomcat 3y ago
Terminals are a central idea affecting Unix process control and hierarchy, and signal delivery. Emulating them was the easier decision that didn't require any changes to the rest of the system. You introduce a virtual terminal device and the rest stays the same. We are still trapped in those basic abstractions of the 1970s without even noticing them, building shiny stuff on top.
- dale_glass 3y ago
  I mean, sure, terminals make some sense. But why are we in 2023, and people are still coming up with fancier versions of "top" that try to draw graphs in text? Every modern computer boots to a graphical console. Every terminal emulator in a GUI runs in a graphical environment. Wouldn't be be much nicer and much less awkward to actually use pixels?
  - jckahn 3y ago
    Reducing everything to a monospaced text character is a beautiful and simplifying constraint, IMO. It gives me as a user a sense of predictable consistency that I really appreciate.
  - deleted 3y ago
    [deleted]
flohofwoe 3y ago
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.
bmitc 3y ago
I agree with what you've said here and in other comments. Terminals are useful, to a degree, but there's so much fruit to be had. And I don't see why we need to be stuck in terminals (I guess terminal emulators is more accurate) as the primary mode of interaction. Warp is interesting enough, but it's a shame it isn't cross-platform to begin with, and I'm dubious about the business model of a terminal product. I think the best hope is that they're purchased by Microsoft, and it gets integrated into VS Code. It also continues to lean into the terminal idea, although it does approach it from scratch, which is nice. https://www.warp.dev/ https://www.warp.dev/ I think the idea of notebook type interfaces is perhaps underrated for scripting purposes. Microsoft's Polyglot Notebooks and .dib format addresses this.
HPsquared 3y ago
This is the downside of organic growth.

bluetomcat 3y ago

Terminals are a central idea affecting Unix process control and hierarchy, and signal delivery. Emulating them was the easier decision that didn't require any changes to the rest of the system. You introduce a virtual terminal device and the rest stays the same. We are still trapped in those basic abstractions of the 1970s without even noticing them, building shiny stuff on top.

dale_glass 3y ago
I mean, sure, terminals make some sense. But why are we in 2023, and people are still coming up with fancier versions of "top" that try to draw graphs in text? Every modern computer boots to a graphical console. Every terminal emulator in a GUI runs in a graphical environment. Wouldn't be be much nicer and much less awkward to actually use pixels?
- jckahn 3y ago
  Reducing everything to a monospaced text character is a beautiful and simplifying constraint, IMO. It gives me as a user a sense of predictable consistency that I really appreciate.
- deleted 3y ago
  [deleted]

flohofwoe 3y ago

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.

bmitc 3y ago

I agree with what you've said here and in other comments. Terminals are useful, to a degree, but there's so much fruit to be had. And I don't see why we need to be stuck in terminals (I guess terminal emulators is more accurate) as the primary mode of interaction. Warp is interesting enough, but it's a shame it isn't cross-platform to begin with, and I'm dubious about the business model of a terminal product. I think the best hope is that they're purchased by Microsoft, and it gets integrated into VS Code. It also continues to lean into the terminal idea, although it does approach it from scratch, which is nice. https://www.warp.dev/ https://www.warp.dev/ I think the idea of notebook type interfaces is perhaps underrated for scripting purposes. Microsoft's Polyglot Notebooks and .dib format addresses this.

HPsquared 3y ago

This is the downside of organic growth.