Rich Command Shells

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It&#x27;s compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it.<p>The command line works with text. The command line remains the best interface I&#x27;ve ever used. It&#x27;s user friendly, composable and available everywhere. It&#x27;s easy to automate and easy to extend.<p>I wish the &quot;command line with pictures&quot; idea would just go away already. It adds nothing for the general public. I can already view pictures on remote machines with X forwarding.<p>Command line with pictures never made it, because there are ten competing standards. With text, everybody just agreed on ASCII and now Unicode&#x2F;UTF8. Text has hundreds of ugly clutches on top of it (Extended ASCII, ANSI, Escape codes, etc, etc). It still works. It&#x27;s still simple. It has its problems, but nowhere near as many problems as GUIs.<p>Those who don&#x27;t understand Unix are doomed to reimplement it... poorly.

I miss TermKit[1]. Its a real shame that the developer abandoned it after it got a lot of hype. There&#x27;s a huge opportunity for someone to come along and make either a new terminal encoding which allows rich, interactive output or extend VT somehow to which allows the same. If you could extend the terminal protocol, you might even be able to get it to work over SSH.<p>HTML+JS seem like the obvious way to do it - even though the web is an awful platform, its standard, cross-platform and fully featured. Its the perfect worse-is-better solution for this.<p>I think the hardest part would be figuring out how to reconcile browser-like UI events and file streams. Maybe you&#x27;d need to make a standardized event serialization format so your process could receive serialized events via stdin or something like that. I think it&#x27;ll be a really hard sell if we have to abandon our unix pipes entirely.<p>[1] <a href="https://github.com/unconed/TermKit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;unconed&#x2F;TermKit</a><p>Previous hackernews discussion around termkit: <a href="https://news.ycombinator.com/item?id=2559734" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2559734</a>

If I might plug a rich command shell I&#x27;m developing: <a href="http://pigshell.com" rel="nofollow">http:&#x2F;&#x2F;pigshell.com</a> (Source at <a href="https://github.com/pigshell/pigshell" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pigshell&#x2F;pigshell</a>)<p>It provides<p>- A shell for the web. Runs in the browser, pure client-side.<p>- File-like abstraction for URLs and other entities exposed by web APIs<p>- Unix-like style of composing commands using pipes.<p>- Visualization using HTML<p>For instance, cp -r &#x2F;gdrive&#x2F;&lt;username&gt; &#x2F;home will backup the contents of your Google Drive to your desktop (see <a href="http://pigshell.com/v/0.6.2/doc/gdrive.html" rel="nofollow">http:&#x2F;&#x2F;pigshell.com&#x2F;v&#x2F;0.6.2&#x2F;doc&#x2F;gdrive.html</a> for details). Replace &#x2F;home with &#x2F;dropbox&#x2F;&lt;username&gt;, and the same command will back up GDrive to Dropbox. And so on.<p>While it is already useful, there is still some work, especially around hardening the file abstraction&#x2F;APIs (and reams of documentation) before before it can be horizontally expanded to support a bunch more APIs and cloud stores. I am actively working on these and expect they&#x27;ll take ~2 months.

I will probably write a &quot;More Rich Command Shells&quot; to cover things I missed here that are important in some way (like Apple&#x27;s MPW).<p>The next thing I want to write though is about building something that has a command shell UI today and thinking about how to do so in a flexible way that works with multiple output devices.

Given all of that, and also Oberon -- &#x27;80s too, and even the Engelbart&#x27;s Demo -- &#x27;68!, I totally every day wonder and can&#x27;t understand why in 2010&#x27;s <i>all</i> of the &quot;modern&quot; OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there <i>was</i> a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling&#x2F;sculpting, possibility of instant communication with significant fraction of all the people in the world, to bring up some). But it still feels like even for them, some things were there, and now are not (sorry for vagueness, but I don&#x27;t have much time now to think about examples, unfortunately. When I&#x27;m gonna finally start this blog thing, one day...).<p>Any theories, anyone? I&#x27;m really curious. Still believe this can be improved, and work on some ideas in my free time, but I often wonder why I have to, and I can&#x27;t already use those beautiful ancient features?

Strange he didn&#x27;t mention Xiki: <a href="http://xsh.org/" rel="nofollow">http:&#x2F;&#x2F;xsh.org&#x2F;</a> <a href="http://xiki.org/" rel="nofollow">http:&#x2F;&#x2F;xiki.org&#x2F;</a>

If you found this interesting, you may also like GCLI (as featured in the Firefox dev tools command line - or you can play with it here: <a href="http://mozilla.github.io/gcli/" rel="nofollow">http:&#x2F;&#x2F;mozilla.github.io&#x2F;gcli&#x2F;</a> ).

If you come to Freiheit.com next week (16. Oct 2014) to the Clojure User Group Meeting in Hamburg&#x2F;Germany, I&#x27;ll demo the Dynamic Windows user interface of a real Symbolics Lisp Machine. Including its command shell called &#x27;Dynamic Lisp Listener&#x27;.<p><a href="http://www.meetup.com/ClojureUserGroupHH/events/207314372/" rel="nofollow">http:&#x2F;&#x2F;www.meetup.com&#x2F;ClojureUserGroupHH&#x2F;events&#x2F;207314372&#x2F;</a>

Slightly off-topic, but the recent surge in responsive UI had me thinking thus: If we are now driven to merge UI logic across different graphical devices, can we think of apps that span both textual and graphical devices?<p>After all, the core functionality of the application remains the same. To use a simple example: when you search for a product online, get a search result list and then select one from the list, couldnt this flow be modeled just the same in both gui and text interfaces?<p>I&#x27;m thinking back to the turbo-pascal style applications of the past that produced full-blown IDEs in text, or the wordstars&#x2F;wordperfects of yore: the UI model that sits behind those apps cannot be much different in principle from the modern day equivalents.<p>Even farther back, there was a time (and probably still is for college assignments) when cli applications had a prompt-read user input-respond cycle, replete with text-based choices to select from and so forth.<p>What if we were to merge the two worlds instead of trying to get one to confirm to the other?

And this is why UNIX shells feel so primitive.

What about the Aurora&#x2F;Eve thing? <a href="https://www.youtube.com/watch?v=L6iUm_Cqx2s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=L6iUm_Cqx2s</a><p>It is a shell, isn&#x27;t it?

How about a declarative and idempotent shell? Well, more declarative and idempotent than bash + the GNU core utils.

CLOS and CLIM always sounded to me like the names of programs you&#x27;d expect to see competing at disc wars, or racing in a lightcycle grid.