12 ms·

The Dawn of a new Command Line Interface (2017)

128 points by harporoeder 6y ago

CJefferson 6y ago
I'm interested in progress in this area, but I'm disappointed the article seems to ignore the existence of powershell, which does some things different to traditional linux shells -- I would at least like a discussion of how this related to powershell.
- rkangel 6y ago
  It is worth noting that this article is from 2017.
  - p_l 6y ago
    Which is over 5 years after Powershell became common.
    - INTPenis 6y ago
      Yes but some would argue Psh didn't become useful until release 6 in 2018.
      - p_l 6y ago
        That would be... an opinion. Not very grounded one unless one's whole base for it was "I couldn't use it on Linux".
      - indymike 6y ago
        As long as I have to write C# wrappers to launch commands like I would in unix with xargs or parallel in PowerShell it's still not the ticket.
        TeMPOraL 6y ago
        You shouldn't need to, unless your PowerShell installation doesn't support Invoke-Command, or ForEach-Object -Parallel...
        indymike 6y ago
        Yeah... shouldn't need to but... there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications. The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper... There's a lot of really cool stuff in PowerShell.
        TeMPOraL 6y ago
        > there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications. Can you tell me more? So I know what to expect when I hit such issue myself. > The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper... Wonder if you need to really break out of PowerShell for this. Recently when doing some scripting at work, I ended up writing .NET code straight in the script. It looks like this: $someCSharp = @" using System; //... public class Foo : Bar { public override object Baz(Quux arg) { //... } } "@ Add-Type $someCSharp -ReferencedAssemblies C:\Path\To\Some\dependency-I-need.dll This makes PowerShell compile your code into an in-memory assembly and make it available in the session, just as if it was an external .NET type. You could probably make a module out of it. Hell, cmdlets are .NET types underneath, you can make new ones from C#, so you could probably make such ad-hoc .NET classes available as PowerShell cmdlets. I suppose using a proper .NET development environment for this would be more kosher; I arrived at the solution described above because my needs were simple, like binding .NET regex engine to SQLite (to get REGEXP operator in queries), or convincing Invoke-RestMethod to stop checking certificate validity. Still, I love the capability, the fact that I can just drop into C# in the middle of the script. It's one of those things that make me think of Lisp machines and Common Lisp the experience of being able to deeply interact with your environment, and the joy of writing "scripts" that are automatically AOT-compiled (like with SBCL implementation of Common Lisp).
- crazyloglad 6y ago
  There was no point in bringing up powershell at the time, its legacy is an entirely different beast from vtXYZ and would invite the next "why isn't hyper.is covered" and "why isn't upterm covered and ..." The fabric under attack was the bastard display server protocol itself and not the parts that tie in with the strong points of Powershell, i.e. shell UI design or data exchange format specifics. This story was continued in a post from yesterday that fizzled, https://arcan-fe.com/2021/04/12/introducing-pipeworld/#pipelines https://arcan-fe.com/2021/04/12/introducing-pipeworld/#pipel...
- yourapostasy 6y ago
  The "key issues to address" list explicitly calls out many of the challenges Powershell manages with its object-based view of the world. It looks like Arcan's SHMIF layer is meant to let developers using Arcan capture rich data and metadata before it gets smooshed into the VTxxx emulation layer and smeared away in a sea of screen formatting characters. Where Arcan cannily (IMHO) differs from Powershell is it acknowledges the transition from existing toolchains will be organic instead of demanding wholesale operational changes to a different processing model. So it splits the data and metadata processing pipeline, exposes it at key points to the developers using Arcan, and lets an emulation layer cover legacy use cases, while enabling Arcan developers to create much richer data representations underneath the covers that can be tapped if desired by users via Lua manipulating the many different Arcan components (I think). This opens up hybrid GUI/TUI/other-interface best-of-breed/mixed-mode options that are unreasonably challenging to implement (especially with sync logic) with current UI stacks. I like this approach more than Powershell's, but it remains to be seen how Arcan handles the guidance of the data and metadata ontology and resultant taxonomy; it is a much deeper problem space than just defining a default namespace, a way to modularly plug into it with extensions, then standing back and letting developers have at it. The way Powershell handled it, introspection and discoverability are out of band instead of a batteries included experience, and module management is still split out of band between Nuget, PrivateGallery, custom solutions, hand-curated Git+Jenkins lash-ups, etc. For my small-scale, personal projects like for my family's intranet, the lack of an opinionated default for at-scale management of these issues is not a problem. But at my clients with dozens, hundreds and even thousands of developers, it presents software engineering management challenges. Solvable, just a developer experience hygiene factor I'd rather not deal with because solving it adds zero business value, it's just the cost of doing business.
- donatj 6y ago
  Is it possible to return structured data in PowerShell from non-.Net languages? I am genuinely asking here, it’s been years since I’ve poked it. If not though that seems like an enormous stumbling block.
  - kaba0 6y ago
    Well, it can export as json, xml and I’m sure some other formats as well, so in principle it can.
    - rbanffy 6y ago
      That sounds interesting, but either programs deal with schema transforms, or we'll have to write a lot of that kind of logic in XSLT or jq (kind of the same stuff we do with cut, sed, awk, sort and grep for unstructured streams). Not sure it's that useful a feature unless the domain of the programs is narrow.
      - kaba0 6y ago
        To be honest, I’ve been thinking about a shell based on the JVM. Especially now with GraalVM, you can have truly polyglot programs running on top of it, with inlinig cross-language boundaries! But of course native code execution should be “bootstrapped” into that world somehow. (Actually, it can use LLVM IR and that as well can run a C function on js objects which is phenomenal, but people do want to run native software from a shell)
        rbanffy 6y ago
        While you'll be able to invoke methods on returned objects, if you are piping stuff, you'll still need to deal with hammering the output of one program into the input of another.
      - TeMPOraL 6y ago
        I think it could be useful - from PowerShell's perspective, all you need is to wrap your "classical" executables to somehow accept and emit .NET objects, and you can carry on from there. Importantly, no more writing parsers in the pipeline or in your scripts. I could see a whole library of such wrappers being built for common executables (and new popular OSS CLI tools could provide their own wrapper along with the tool).
- Koshkin 6y ago
  To be fair, the article seems to be more about the terminal emulation and the limitations it puts on the CLI rather than about the shell language.
  - rbanffy 6y ago
    Proper VT emulation gives you multiple fonts, mouse and windows.
- pjmlp 6y ago
  Powershell is great, it is the closest of the REPL experience from Xerox PARC, Lisp Machines and ETHZ workstations. The experience could be replicated in UNIX shells, but noone sems to care to actually go down that path.
  - TeMPOraL 6y ago
    I feel that the closest we can get to a Lisp machine with modern components right now would be to get PowerShell, Emacs and StumpWM (or EXWM) to deeply interoperate.
  - ticviking 6y ago
    I mean it's possible to run PowerShell on Linux, but PowerShell has some pretty significant rough edges, including a pretty painful performance story for something I want to use as a UI.
    - pjmlp 6y ago
      It is also a matter of culture, as mentioned you could have a UNIX shell being structured, able to directly interact with shared objects, IPC with running applications, yet very few do it.
- marlowe221 6y ago
  I work in a Windows shop (security compliance reasons for federal government contracts). Before I got this job I was pretty much only developing in Linux. Honestly? Powershell is pretty cool, though it feels a little strange to admit that. It has it's own very powerful syntax and virtually all of the common Bash commands are now aliased by default, so it's pretty smooth transition for the basic stuff.
  - richardwhiuk 6y ago
    See https://github.com/PowerShell/PowerShell/pull/1901 https://github.com/PowerShell/PowerShell/pull/1901
deleted 6y ago
[deleted]
Semaphor 6y ago
This didn’t get any comments when it was submitted in 2017, but there were some 2 years ago: https://news.ycombinator.com/item?id=21645181 https://news.ycombinator.com/item?id=21645181
- underwater 6y ago
  > Those who don't understand Unix are condemned to reinvent it, poorly. What a low value and needlessly dismissive comment. And based on HN's track record it probably means Arcan actually has a shot.
  - Koshkin 6y ago
    Agreed. (MS-DOS may have “reinvented UNIX, poorly,” but there do exist other OS and other approaches to UI that enjoy a large and happy user base.)
    - bjornjajayaja 6y ago
      Honestly one could argue that DOS has some merit beyond Unix. It’s simple command line interface expects users will program in other languages like C or assembly. It’s more directly interaction with the machine. Sure it had limitations like file name lengths etc back in the day, but I think many Unix shells are overly complex and ought to yield to more suitable languages like Perl.
      - hashkb 6y ago
        Many of the standard unix tools are not written in sh. They're written in C. Am I missing something in your comment?
        ticviking 6y ago
        > It’s simple command line interface expects users will program in other languages like C or assembly. I think the point here is that DOS explicitly rejects the composition that pipes enable, in exchange for the ability to just hand "the whole system" over to a programmer.
simias 6y ago
I feel towards the unx shell the same way I feel towards Vim: there's quite a bit of cruft, some poor decisions, quite a bit I'd do differently if I decided to write my own implementation from scratch. But on the other hand it mostly works well and I've learned over the years how to work around the awkward parts. It's easy to make a laundry list of the ways the traditional unix shell falls short. The problem is creating an alternative that's superior enough to warrant learning something new and consensual enough that it can get mainstream appeal. The article acknowledges that: >There is arguably a rift here between those that prefer the ‘shove it in a browser’ or flashy UIs that animate and morph as you interact, and those that prefer staring into a text editor. It seems to me that the former category gets all the fancy new toys, while the latter mutters on about insurmountable levels of legacy. What I personally want is many more “one- purpose” TUIs and for them to be much easier to develop. They need to be simpler, more consistent, obvious to use, and more configurable. That’s nice and dreamy, but how are “we” supposed to get there? But then I argue that they jumps the shark a bit. As far as I can tell the Arcan project seems more preoccupied with reaching feature-parity with Xorg than actually improving the CLI. And I'm sure for some people that's great, but for me personally that makes it a funny novelty thing that I don't see myself using. It reminds me when I first saw compiz ~15 years ago, where you had virtual desktops on a rotating 3D cube with all sorts of weird visual effects[1]. It looked cool, but I never actually used it because it wasn't practical and I had no use for it. On the other hand I'd love for a better CLI implementation, better pipes, easier debugging, a more expressive scripting language, better task control, better feedback. But then we went full circle to the core of the issue: everybody agrees that the unx CLI sort of sucks, but we don't really agree on what exactly needs fixing. [1] https://youtu.be/B-FVJoZ-zwI https://youtu.be/B-FVJoZ-zwI
- dale_glass 6y ago
  That's odd, I found the Compiz cube to be helpful actually. As a graphics effect it's about as basic as it can get -- even the venerable GLX Gears is more complex. And I found it to actually increase usability because it visually and very intuitively showed you the movement, so it made organization a bit neater. It made it easier to keep a mental map of what was where, because it could be arranged spatially. If anything, it didn't go far enough. I wanted more faces, and the possibility of working in a "zoomed out" state, for when I need to look at a whole bunch of stuff at once. The real novelty stuff to me were the Enlightenment effects like the water effect on the bottom of the screen -- now that chewed up CPU and did nothing of actual use.
globular-toast 6y ago
This seems to be more about text-based user interfaces rather than command-line interfaces. I wonder if the author has considered Emacs? A lot of people think of Emacs as a "text editor", but that's far from the truth of what it is. It's really a Lisp interpreter and toolkit especially designed for making text-based user interfaces.
- yourapostasy 6y ago
  It looks like the problem space the author is addressing is broader than Emacs; they seem to want to make TUI's one of many different, first-class-citizen presentation layer options, interacting with many different input mechanisms. A Lego approach to UI frameworks basically as far as I can tell. It would be interesting if there was an Arcan-philosophy UI framework in CL for an updated Climacs on top of a bare metal Lisp environment, for a turtles-all-the-way-down CL experience. It would open up interesting interactions with Emacs that are an unreasonably big pain to implement today, like buffers that manipulate view ports into observability data under a pluggable UI that renders graphically a graph data-oriented view of the discovered structure of the data under an investigation taking notes into a Jupiter-like notebook with rich multimedia data, for instance.
  - taeric 6y ago
    I'd actually be surprised if you couldn't do some of this with emacs today. Falling back to the text is just hella repeatable in ways that most binary forms are not.
willis936 6y ago
One issue with windows command line I’ve run into recently is text rendering performance. Running cxxmatrix at a high resolution brings even a modestly powerful machine to its knees. cxxmatrix crashes alacritty, but I have found that running VcXsrv and urxvt from wsl yields much better cxxmatrix performance than when running from wsl. Here is a related issue. There are many cousin issues. https://github.com/microsoft/terminal/issues/2047 https://github.com/microsoft/terminal/issues/2047
_pmf_ 6y ago
Some very true points. The fact that terminal protocols are modeled on top of linear output streams is a historical accident.
- Koshkin 6y ago
  TN5250 being one of the famous exceptions.
MayeulC 6y ago
One thing I've been thinking of: how about making typed file descriptors? Besides stdio and stdout, one of the best-accepted conventions on modern operating systems running a graphical shell seems to be the clipboard. Programs can offer different mime types trough a clipboard, so why not do so trough a pipe or file descriptor? That would bring us a bit closer to powershell, while remaining backwards-compatible. cat pipe.dot <- text/plain | dot <- text/plain, text/dot, image/svg+xml, application/pdf, application/postscript, etc | xclip Instead of xclip in the above example, one could use an image viewer, a multiplexer a bit like tee (1) but to redirect to standard input, etc. One could force a pipe to filter out some mimetypes, or use a program dedicated to that. One could imagine bidirectional communications over a channel. xeyes | ssh somehost record-audio.sh | mail someone@somewhere nmtui | guitoolkit rsync | guitoolkit ssh somehost rsync | guitoolkit Basically, building on the strengths of UNIX.
- TeMPOraL 6y ago
  Come to think of it, you could abuse NTFS Alternate Data Streams for this. Imagine: > # See alternate data streams > Get-Item diagram.dot -Stream * Stream Length ------ ------ :$DATA 123 text/plain 4444 image/svg+xml 65432 image/png 456134 > # Send the whole bulk > Get-Item diagram.dot -Stream * | ... > #... or pick just one: > Get-Content diagram.dot -Stream "image/svg+xml" | Send-Email .... Would have to ensure everything is aware of the streams and the convention, though, so that you wouldn't accidentally truncate them when copying files around.
  - MayeulC 6y ago
    Ah, that's interesting, thanks for mentioning it. That's pretty much what I mean, but on arbitrary file descriptors instead of files. I agree that both ends need to be aware of these extra formats to make use of them, but just like with clipboards, programs could always fall back to pretending only text/plain exists :)
    - HelloNurse 6y ago
nottorp 6y ago
At a quick look this means you'll need to use a special ssh client to use their framework? Terminals are decoupled from the actual application for a good reason...
- em-bee 6y ago
  yes, but that's exactly why we are stuck and can't evolve. if we want to get something better than current terminals, a new protocol and client are needed. take mosh for example. it uses a different protocol than ssh too, which adds some interesting features. and it replaces ssh (except for relying on ssh to make the initial authentication) there is no reason why another alternative to ssh could not be created. if it's good, it will catch on. just like mosh which is slowly growing, and also like ssh was in the very beginning when it slowly grew to replace telnet.
  - nottorp 6y ago
    Yeah but that thing seems to suffer from architecture astronautitis and a desire to take over every function just like systemd... While, you know, ssh carries your bits and the terminal displays said bits, just like it displayed the telnet bits before. Decoupled is good.
    - em-bee 6y ago
      fair point. actually, i think i may have misunderstood the problem. ssh can tunnel anything, so whatever new protocol is devised, it should actually work though ssh. also i am not disputing that a new system could not be decoupled. i am just concerned that it should not be required to work with ssh if that becomes a limiting factor. architecture astronautitis is certainly bad, but maybe it's possible to create an implementation with a limited subset of features that are actually practical.
xbar 6y ago
All the Arcanspace stuff is cool. The problems are real. The pieces and principles force me to think about many of the "skills" I have acquired in order to work on various shells and desktops as burdens. I can't bring myself to change to (or develop) pipeworld/durden-esque environments (yet?), I am drawn to them because I have a strong, natural alignment to the principles the author espouses and develops against. Keep up the good work.
theamk 6y ago
this is interesting -- I was expecting to see a replacement for existng ttys, and was planning to complain about ssh forwarding, redirection, etc... instead, they explicitly say: > Recall that the prime target now is local text-oriented, command line interfaces – not changing or tampering with the awk | sed | grep | … flow, that’s an entirely different beast. So I'd call this a "TUI" (text user interface), and the proposed schema replaces X11 or Wayland, not xterm.
legulere 6y ago
What I find an interesting is command interfaces in GUI applications. For instance ctrl + shift + p / cmd + shift + p menu of visual studio code or the new windows terminal, or the commands in slack. A GUI gives way more options for displaying information especially for auto-complete even while staying in a keyboard-only interface.
taeric 6y ago
I'm not sure I agree with some of the key issues. In particular, the points on code/data and user input versus pasted input. By and large, I like knowing that I am in control of what I send a program on the terminal. It is actually maddening when I go to paste into a word processor and it doesn't just bring over the text. Or when I go to script a program, but it doesn't act sanely when driven by a script instead of by a user. Where sanely is, exactly the same. There are times when I have taken advantage of eshell to inline images and such. That said, I don't use many tui style programs, other than emacs. And I greatly appreciate that the majority of emacs buffers are textual buffers.
dan-robertson 6y ago
I think emacs is a good example of a terminal program (not really command line) that made a good success out of becoming more gui and I think it shows a lot of the limitations of the terminal emulators. In a gui you easily get all the colours and not many weird duplicate keyboard shortcuts (exceptions are eg TAB vs C-i and M- vs ESC). You can have images and clicking and middle click paste and multiple fonts and some OS integration. But the interface still remains a fundamentally mutable text-based thing. For something completely different: https://hisham.hm/userland/ https://hisham.hm/userland/
shashurup 6y ago
This is one of my favourite itches to scratch. Initially it was inspired by TermKit and since then I pay attention to such endevours. Intuitively I feel that we can do better on the presentation side. It is also tempting to refactor pipelines to use structured data - at first sight this would help avoiding all this plaintext parsing glue which hides otherwise elegant logic in your pipelines. However, digging deeper into possible solution frustration creeps in :( In my case it started when I tried to collect real world use cases for "rich terminal": cat image.png # that is pretty straitforward cat *.png | gallery -3 # displays picture gallery in 3 columns cat some_data | plot .... # hm... not that I use this frequently ..... psql -c "select * from customer;" # hm.. I do need some kind of grid control here. Heck, do I really need to bring such a complex thing here? Ok, I'm a bit stuck, lets postpone this and think about the implementation. The obvious choice to make some shortcut such as HTML. However, here comes JS and I'm totally unsure that this behemot is what I wanted. Improving VT100? Most likely this will end up with a brand new 15th standard. No luck, lets postpone. Structured data. Lets scratch another itch - model some basic commands using Clojure to build commands and represent structured data. ls, find, cat, grep. After a good start with producing file tree, flattening and filtering it with core Clojure function it becomes clear that I need some kind of DSL for "find" so that it would be as concise and easy type as with "find". Блин!!!! Lets wait for the next such post on HN to start over.
- watersb 6y ago
  PowerShell runs on top of dotNET, and the pipe operators pass structured data, xml or json. It's not as fluid for me as a POSIX environment, 35 years of shell muscle memory. PowerShell is a bumpy road: some commands are super powerful, and some bits have strange limitations. But it's certainly encouraging that people are getting stuff done.

128 points by harporoeder 6y ago

I'm interested in progress in this area, but I'm disappointed the article seems to ignore the existence of powershell, which does some things different to traditional linux shells -- I would at least like a discussion of how this related to powershell.

rkangel 6y ago
It is worth noting that this article is from 2017.
- p_l 6y ago
  Which is over 5 years after Powershell became common.
  - INTPenis 6y ago
    Yes but some would argue Psh didn't become useful until release 6 in 2018.
    - p_l 6y ago
      That would be... an opinion. Not very grounded one unless one's whole base for it was "I couldn't use it on Linux".
    - indymike 6y ago
      As long as I have to write C# wrappers to launch commands like I would in unix with xargs or parallel in PowerShell it's still not the ticket.
      - TeMPOraL 6y ago
        You shouldn't need to, unless your PowerShell installation doesn't support Invoke-Command, or ForEach-Object -Parallel...
        indymike 6y ago
        Yeah... shouldn't need to but... there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications. The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper... There's a lot of really cool stuff in PowerShell.
        TeMPOraL 6y ago
        > there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications. Can you tell me more? So I know what to expect when I hit such issue myself. > The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper... Wonder if you need to really break out of PowerShell for this. Recently when doing some scripting at work, I ended up writing .NET code straight in the script. It looks like this: $someCSharp = @" using System; //... public class Foo : Bar { public override object Baz(Quux arg) { //... } } "@ Add-Type $someCSharp -ReferencedAssemblies C:\Path\To\Some\dependency-I-need.dll This makes PowerShell compile your code into an in-memory assembly and make it available in the session, just as if it was an external .NET type. You could probably make a module out of it. Hell, cmdlets are .NET types underneath, you can make new ones from C#, so you could probably make such ad-hoc .NET classes available as PowerShell cmdlets. I suppose using a proper .NET development environment for this would be more kosher; I arrived at the solution described above because my needs were simple, like binding .NET regex engine to SQLite (to get REGEXP operator in queries), or convincing Invoke-RestMethod to stop checking certificate validity. Still, I love the capability, the fact that I can just drop into C# in the middle of the script. It's one of those things that make me think of Lisp machines and Common Lisp the experience of being able to deeply interact with your environment, and the joy of writing "scripts" that are automatically AOT-compiled (like with SBCL implementation of Common Lisp).
crazyloglad 6y ago
There was no point in bringing up powershell at the time, its legacy is an entirely different beast from vtXYZ and would invite the next "why isn't hyper.is covered" and "why isn't upterm covered and ..." The fabric under attack was the bastard display server protocol itself and not the parts that tie in with the strong points of Powershell, i.e. shell UI design or data exchange format specifics. This story was continued in a post from yesterday that fizzled, https://arcan-fe.com/2021/04/12/introducing-pipeworld/#pipelines https://arcan-fe.com/2021/04/12/introducing-pipeworld/#pipel...
yourapostasy 6y ago
The "key issues to address" list explicitly calls out many of the challenges Powershell manages with its object-based view of the world. It looks like Arcan's SHMIF layer is meant to let developers using Arcan capture rich data and metadata before it gets smooshed into the VTxxx emulation layer and smeared away in a sea of screen formatting characters. Where Arcan cannily (IMHO) differs from Powershell is it acknowledges the transition from existing toolchains will be organic instead of demanding wholesale operational changes to a different processing model. So it splits the data and metadata processing pipeline, exposes it at key points to the developers using Arcan, and lets an emulation layer cover legacy use cases, while enabling Arcan developers to create much richer data representations underneath the covers that can be tapped if desired by users via Lua manipulating the many different Arcan components (I think). This opens up hybrid GUI/TUI/other-interface best-of-breed/mixed-mode options that are unreasonably challenging to implement (especially with sync logic) with current UI stacks. I like this approach more than Powershell's, but it remains to be seen how Arcan handles the guidance of the data and metadata ontology and resultant taxonomy; it is a much deeper problem space than just defining a default namespace, a way to modularly plug into it with extensions, then standing back and letting developers have at it. The way Powershell handled it, introspection and discoverability are out of band instead of a batteries included experience, and module management is still split out of band between Nuget, PrivateGallery, custom solutions, hand-curated Git+Jenkins lash-ups, etc. For my small-scale, personal projects like for my family's intranet, the lack of an opinionated default for at-scale management of these issues is not a problem. But at my clients with dozens, hundreds and even thousands of developers, it presents software engineering management challenges. Solvable, just a developer experience hygiene factor I'd rather not deal with because solving it adds zero business value, it's just the cost of doing business.
donatj 6y ago
Is it possible to return structured data in PowerShell from non-.Net languages? I am genuinely asking here, it’s been years since I’ve poked it. If not though that seems like an enormous stumbling block.
- kaba0 6y ago
  Well, it can export as json, xml and I’m sure some other formats as well, so in principle it can.
  - rbanffy 6y ago
    That sounds interesting, but either programs deal with schema transforms, or we'll have to write a lot of that kind of logic in XSLT or jq (kind of the same stuff we do with cut, sed, awk, sort and grep for unstructured streams). Not sure it's that useful a feature unless the domain of the programs is narrow.
    - kaba0 6y ago
      To be honest, I’ve been thinking about a shell based on the JVM. Especially now with GraalVM, you can have truly polyglot programs running on top of it, with inlinig cross-language boundaries! But of course native code execution should be “bootstrapped” into that world somehow. (Actually, it can use LLVM IR and that as well can run a C function on js objects which is phenomenal, but people do want to run native software from a shell)
      - rbanffy 6y ago
        While you'll be able to invoke methods on returned objects, if you are piping stuff, you'll still need to deal with hammering the output of one program into the input of another.
    - TeMPOraL 6y ago
      I think it could be useful - from PowerShell's perspective, all you need is to wrap your "classical" executables to somehow accept and emit .NET objects, and you can carry on from there. Importantly, no more writing parsers in the pipeline or in your scripts. I could see a whole library of such wrappers being built for common executables (and new popular OSS CLI tools could provide their own wrapper along with the tool).
Koshkin 6y ago
To be fair, the article seems to be more about the terminal emulation and the limitations it puts on the CLI rather than about the shell language.
- rbanffy 6y ago
  Proper VT emulation gives you multiple fonts, mouse and windows.
pjmlp 6y ago
Powershell is great, it is the closest of the REPL experience from Xerox PARC, Lisp Machines and ETHZ workstations. The experience could be replicated in UNIX shells, but noone sems to care to actually go down that path.
- TeMPOraL 6y ago
  I feel that the closest we can get to a Lisp machine with modern components right now would be to get PowerShell, Emacs and StumpWM (or EXWM) to deeply interoperate.
- ticviking 6y ago
  I mean it's possible to run PowerShell on Linux, but PowerShell has some pretty significant rough edges, including a pretty painful performance story for something I want to use as a UI.
  - pjmlp 6y ago
    It is also a matter of culture, as mentioned you could have a UNIX shell being structured, able to directly interact with shared objects, IPC with running applications, yet very few do it.
marlowe221 6y ago
I work in a Windows shop (security compliance reasons for federal government contracts). Before I got this job I was pretty much only developing in Linux. Honestly? Powershell is pretty cool, though it feels a little strange to admit that. It has it's own very powerful syntax and virtually all of the common Bash commands are now aliased by default, so it's pretty smooth transition for the basic stuff.
- richardwhiuk 6y ago
  See https://github.com/PowerShell/PowerShell/pull/1901 https://github.com/PowerShell/PowerShell/pull/1901

deleted 6y ago

[deleted]

Semaphor 6y ago

This didn’t get any comments when it was submitted in 2017, but there were some 2 years ago: https://news.ycombinator.com/item?id=21645181 https://news.ycombinator.com/item?id=21645181

underwater 6y ago
> Those who don't understand Unix are condemned to reinvent it, poorly. What a low value and needlessly dismissive comment. And based on HN's track record it probably means Arcan actually has a shot.
- Koshkin 6y ago
  Agreed. (MS-DOS may have “reinvented UNIX, poorly,” but there do exist other OS and other approaches to UI that enjoy a large and happy user base.)
  - bjornjajayaja 6y ago
    Honestly one could argue that DOS has some merit beyond Unix. It’s simple command line interface expects users will program in other languages like C or assembly. It’s more directly interaction with the machine. Sure it had limitations like file name lengths etc back in the day, but I think many Unix shells are overly complex and ought to yield to more suitable languages like Perl.
    - hashkb 6y ago
      Many of the standard unix tools are not written in sh. They're written in C. Am I missing something in your comment?
      - ticviking 6y ago
        > It’s simple command line interface expects users will program in other languages like C or assembly. I think the point here is that DOS explicitly rejects the composition that pipes enable, in exchange for the ability to just hand "the whole system" over to a programmer.

simias 6y ago

I feel towards the unx shell the same way I feel towards Vim: there's quite a bit of cruft, some poor decisions, quite a bit I'd do differently if I decided to write my own implementation from scratch. But on the other hand it mostly works well and I've learned over the years how to work around the awkward parts. It's easy to make a laundry list of the ways the traditional unix shell falls short. The problem is creating an alternative that's superior enough to warrant learning something new and consensual enough that it can get mainstream appeal. The article acknowledges that: >There is arguably a rift here between those that prefer the ‘shove it in a browser’ or flashy UIs that animate and morph as you interact, and those that prefer staring into a text editor. It seems to me that the former category gets all the fancy new toys, while the latter mutters on about insurmountable levels of legacy. What I personally want is many more “one- purpose” TUIs and for them to be much easier to develop. They need to be simpler, more consistent, obvious to use, and more configurable. That’s nice and dreamy, but how are “we” supposed to get there? But then I argue that they jumps the shark a bit. As far as I can tell the Arcan project seems more preoccupied with reaching feature-parity with Xorg than actually improving the CLI. And I'm sure for some people that's great, but for me personally that makes it a funny novelty thing that I don't see myself using. It reminds me when I first saw compiz ~15 years ago, where you had virtual desktops on a rotating 3D cube with all sorts of weird visual effects[1]. It looked cool, but I never actually used it because it wasn't practical and I had no use for it. On the other hand I'd love for a better CLI implementation, better pipes, easier debugging, a more expressive scripting language, better task control, better feedback. But then we went full circle to the core of the issue: everybody agrees that the unx CLI sort of sucks, but we don't really agree on what exactly needs fixing. [1] https://youtu.be/B-FVJoZ-zwI https://youtu.be/B-FVJoZ-zwI

dale_glass 6y ago
That's odd, I found the Compiz cube to be helpful actually. As a graphics effect it's about as basic as it can get -- even the venerable GLX Gears is more complex. And I found it to actually increase usability because it visually and very intuitively showed you the movement, so it made organization a bit neater. It made it easier to keep a mental map of what was where, because it could be arranged spatially. If anything, it didn't go far enough. I wanted more faces, and the possibility of working in a "zoomed out" state, for when I need to look at a whole bunch of stuff at once. The real novelty stuff to me were the Enlightenment effects like the water effect on the bottom of the screen -- now that chewed up CPU and did nothing of actual use.

globular-toast 6y ago

This seems to be more about text-based user interfaces rather than command-line interfaces. I wonder if the author has considered Emacs? A lot of people think of Emacs as a "text editor", but that's far from the truth of what it is. It's really a Lisp interpreter and toolkit especially designed for making text-based user interfaces.

yourapostasy 6y ago
It looks like the problem space the author is addressing is broader than Emacs; they seem to want to make TUI's one of many different, first-class-citizen presentation layer options, interacting with many different input mechanisms. A Lego approach to UI frameworks basically as far as I can tell. It would be interesting if there was an Arcan-philosophy UI framework in CL for an updated Climacs on top of a bare metal Lisp environment, for a turtles-all-the-way-down CL experience. It would open up interesting interactions with Emacs that are an unreasonably big pain to implement today, like buffers that manipulate view ports into observability data under a pluggable UI that renders graphically a graph data-oriented view of the discovered structure of the data under an investigation taking notes into a Jupiter-like notebook with rich multimedia data, for instance.
- taeric 6y ago
  I'd actually be surprised if you couldn't do some of this with emacs today. Falling back to the text is just hella repeatable in ways that most binary forms are not.

willis936 6y ago

One issue with windows command line I’ve run into recently is text rendering performance. Running cxxmatrix at a high resolution brings even a modestly powerful machine to its knees. cxxmatrix crashes alacritty, but I have found that running VcXsrv and urxvt from wsl yields much better cxxmatrix performance than when running from wsl. Here is a related issue. There are many cousin issues. https://github.com/microsoft/terminal/issues/2047 https://github.com/microsoft/terminal/issues/2047

_pmf_ 6y ago

Some very true points. The fact that terminal protocols are modeled on top of linear output streams is a historical accident.

Koshkin 6y ago
TN5250 being one of the famous exceptions.

MayeulC 6y ago

One thing I've been thinking of: how about making typed file descriptors? Besides stdio and stdout, one of the best-accepted conventions on modern operating systems running a graphical shell seems to be the clipboard. Programs can offer different mime types trough a clipboard, so why not do so trough a pipe or file descriptor? That would bring us a bit closer to powershell, while remaining backwards-compatible. cat pipe.dot <- text/plain | dot <- text/plain, text/dot, image/svg+xml, application/pdf, application/postscript, etc | xclip Instead of xclip in the above example, one could use an image viewer, a multiplexer a bit like tee (1) but to redirect to standard input, etc. One could force a pipe to filter out some mimetypes, or use a program dedicated to that. One could imagine bidirectional communications over a channel. xeyes | ssh somehost record-audio.sh | mail someone@somewhere nmtui | guitoolkit rsync | guitoolkit ssh somehost rsync | guitoolkit Basically, building on the strengths of UNIX.

TeMPOraL 6y ago
Come to think of it, you could abuse NTFS Alternate Data Streams for this. Imagine: > # See alternate data streams > Get-Item diagram.dot -Stream * Stream Length ------ ------ :$DATA 123 text/plain 4444 image/svg+xml 65432 image/png 456134 > # Send the whole bulk > Get-Item diagram.dot -Stream * | ... > #... or pick just one: > Get-Content diagram.dot -Stream "image/svg+xml" | Send-Email .... Would have to ensure everything is aware of the streams and the convention, though, so that you wouldn't accidentally truncate them when copying files around.
- MayeulC 6y ago
  Ah, that's interesting, thanks for mentioning it. That's pretty much what I mean, but on arbitrary file descriptors instead of files. I agree that both ends need to be aware of these extra formats to make use of them, but just like with clipboards, programs could always fall back to pretending only text/plain exists :)
  - HelloNurse 6y ago

nottorp 6y ago

At a quick look this means you'll need to use a special ssh client to use their framework? Terminals are decoupled from the actual application for a good reason...

em-bee 6y ago
yes, but that's exactly why we are stuck and can't evolve. if we want to get something better than current terminals, a new protocol and client are needed. take mosh for example. it uses a different protocol than ssh too, which adds some interesting features. and it replaces ssh (except for relying on ssh to make the initial authentication) there is no reason why another alternative to ssh could not be created. if it's good, it will catch on. just like mosh which is slowly growing, and also like ssh was in the very beginning when it slowly grew to replace telnet.
- nottorp 6y ago
  Yeah but that thing seems to suffer from architecture astronautitis and a desire to take over every function just like systemd... While, you know, ssh carries your bits and the terminal displays said bits, just like it displayed the telnet bits before. Decoupled is good.
  - em-bee 6y ago
    fair point. actually, i think i may have misunderstood the problem. ssh can tunnel anything, so whatever new protocol is devised, it should actually work though ssh. also i am not disputing that a new system could not be decoupled. i am just concerned that it should not be required to work with ssh if that becomes a limiting factor. architecture astronautitis is certainly bad, but maybe it's possible to create an implementation with a limited subset of features that are actually practical.

xbar 6y ago

All the Arcanspace stuff is cool. The problems are real. The pieces and principles force me to think about many of the "skills" I have acquired in order to work on various shells and desktops as burdens. I can't bring myself to change to (or develop) pipeworld/durden-esque environments (yet?), I am drawn to them because I have a strong, natural alignment to the principles the author espouses and develops against. Keep up the good work.

theamk 6y ago

this is interesting -- I was expecting to see a replacement for existng ttys, and was planning to complain about ssh forwarding, redirection, etc... instead, they explicitly say: > Recall that the prime target now is local text-oriented, command line interfaces – not changing or tampering with the awk | sed | grep | … flow, that’s an entirely different beast. So I'd call this a "TUI" (text user interface), and the proposed schema replaces X11 or Wayland, not xterm.

legulere 6y ago

What I find an interesting is command interfaces in GUI applications. For instance ctrl + shift + p / cmd + shift + p menu of visual studio code or the new windows terminal, or the commands in slack. A GUI gives way more options for displaying information especially for auto-complete even while staying in a keyboard-only interface.

taeric 6y ago

I'm not sure I agree with some of the key issues. In particular, the points on code/data and user input versus pasted input. By and large, I like knowing that I am in control of what I send a program on the terminal. It is actually maddening when I go to paste into a word processor and it doesn't just bring over the text. Or when I go to script a program, but it doesn't act sanely when driven by a script instead of by a user. Where sanely is, exactly the same. There are times when I have taken advantage of eshell to inline images and such. That said, I don't use many tui style programs, other than emacs. And I greatly appreciate that the majority of emacs buffers are textual buffers.

dan-robertson 6y ago

I think emacs is a good example of a terminal program (not really command line) that made a good success out of becoming more gui and I think it shows a lot of the limitations of the terminal emulators. In a gui you easily get all the colours and not many weird duplicate keyboard shortcuts (exceptions are eg TAB vs C-i and M- vs ESC). You can have images and clicking and middle click paste and multiple fonts and some OS integration. But the interface still remains a fundamentally mutable text-based thing. For something completely different: https://hisham.hm/userland/ https://hisham.hm/userland/

shashurup 6y ago

This is one of my favourite itches to scratch. Initially it was inspired by TermKit and since then I pay attention to such endevours. Intuitively I feel that we can do better on the presentation side. It is also tempting to refactor pipelines to use structured data - at first sight this would help avoiding all this plaintext parsing glue which hides otherwise elegant logic in your pipelines. However, digging deeper into possible solution frustration creeps in :( In my case it started when I tried to collect real world use cases for "rich terminal": cat image.png # that is pretty straitforward cat *.png | gallery -3 # displays picture gallery in 3 columns cat some_data | plot .... # hm... not that I use this frequently ..... psql -c "select * from customer;" # hm.. I do need some kind of grid control here. Heck, do I really need to bring such a complex thing here? Ok, I'm a bit stuck, lets postpone this and think about the implementation. The obvious choice to make some shortcut such as HTML. However, here comes JS and I'm totally unsure that this behemot is what I wanted. Improving VT100? Most likely this will end up with a brand new 15th standard. No luck, lets postpone. Structured data. Lets scratch another itch - model some basic commands using Clojure to build commands and represent structured data. ls, find, cat, grep. After a good start with producing file tree, flattening and filtering it with core Clojure function it becomes clear that I need some kind of DSL for "find" so that it would be as concise and easy type as with "find". Блин!!!! Lets wait for the next such post on HN to start over.

watersb 6y ago
PowerShell runs on top of dotNET, and the pipe operators pass structured data, xml or json. It's not as fluid for me as a POSIX environment, 35 years of shell muscle memory. PowerShell is a bumpy road: some commands are super powerful, and some bits have strange limitations. But it's certainly encouraging that people are getting stuff done.