One thing I've been thinking of: how about making typed file descriptors?<p>Besides stdio and stdout, one of the best-accepted conventions on modern operating systems running a graphical shell seems to be the clipboard.<p>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.<p><pre><code> cat pipe.dot <- text/plain
| dot <- text/plain, text/dot, image/svg+xml, application/pdf, application/postscript, etc
| xclip
</code></pre>
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.<p><pre><code> xeyes | ssh somehost
record-audio.sh | mail someone@somewhere
nmtui | guitoolkit
rsync | guitoolkit
ssh somehost rsync | guitoolkit
</code></pre>
Basically, building on the strengths of UNIX.
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.
This didn’t get any comments when it was submitted in 2017, but there were some 2 years ago: <a href="https://news.ycombinator.com/item?id=21645181" rel="nofollow">https://news.ycombinator.com/item?id=21645181</a>
I feel towards the un<i>x 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.<p>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.<p>The article acknowledges that:<p>>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?<p>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.<p>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.<p>But then we went full circle to the core of the issue: everybody agrees that the un</i>x CLI sort of sucks, but we don't really agree on what exactly needs fixing.<p>[1] <a href="https://youtu.be/B-FVJoZ-zwI" rel="nofollow">https://youtu.be/B-FVJoZ-zwI</a>
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.
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.
All the Arcanspace stuff is cool. The problems are real.<p>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.<p>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.<p>Keep up the good work.
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 <i>much</i> better cxxmatrix performance than when running from wsl.<p>Here is a related issue. There are many cousin issues.<p><a href="https://github.com/microsoft/terminal/issues/2047" rel="nofollow">https://github.com/microsoft/terminal/issues/2047</a>
This is one of my favourite itches to scratch. Initially it was inspired by TermKit and since then I pay attention to such endevours.<p>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.<p>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":<p>cat image.png # that is pretty straitforward<p>cat *.png | gallery -3 # displays picture gallery in 3 columns<p>cat some_data | plot .... # hm... not that I use this frequently<p>.....<p>psql -c "select * from customer;" # hm.. I do need some kind of grid control here.<p>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.<p>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.<p>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".<p>Блин!!!!
Lets wait for the next such post on HN to start over.
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.<p>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.<p>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.
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.<p>For something completely different: <a href="https://hisham.hm/userland/" rel="nofollow">https://hisham.hm/userland/</a>
At a quick look this means you'll need to use a special ssh client to use their framework?<p>Terminals are decoupled from the actual application for a good reason...
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:<p>> 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.<p>So I'd call this a "TUI" (text user interface), and the proposed schema replaces X11 or Wayland, not xterm.