Live data from Hacker News

Rich Command Shells

waywardmonkeys.org

1–10 of 101 posts

Re: Rich Command Shells

#2
I will probably write a "More Rich Command Shells" to cover things I missed here that are important in some way (like Apple's MPW).

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.

Re: Rich Command Shells

#3
post #2

I will probably write a "More Rich Command Shells" to cover things I missed here that are important in some way (like Apple's MPW). 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.

Thanks for that article.

I'm often thinking about how to present/"unify" these:

  - command (statements validated by some token),
  - repl (expression, less side-effect driven than the previous one), 
  - unary/immediate mode (each input event is interpretable right away, direct mapping between input and action), 
  - n-ary/non-immediate mode (some parsing occurs, gathering a few tokens into a higher level construct)
  - non keyboard based UI/UX (some sofware like Maya have proper separation, most mouse events have direct translation into object methods)

Re: Rich Command Shells

#4
post #2

I will probably write a "More Rich Command Shells" to cover things I missed here that are important in some way (like Apple's MPW). 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.

[deleted]

Re: Rich Command Shells

#5
I miss TermKit[1]. Its a real shame that the developer abandoned it after it got a lot of hype. There'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.

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.

I think the hardest part would be figuring out how to reconcile browser-like UI events and file streams. Maybe you'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'll be a really hard sell if we have to abandon our unix pipes entirely.

[1] https://github.com/unconed/TermKit

Previous hackernews discussion around termkit: https://news.ycombinator.com/item?id=2559734

Re: Rich Command Shells

#8
post #7

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: http://mozilla.github.io/gcli/ ).

GCLI is interesting, but I didn't mention it because I feel like it focuses more on the issue of command parsing / completion.

That said, that's a great topic to cover! I think GCLI does a pretty good job of command completion. The Lisp Machine did as well. I have friends who love some of the router CLIs, but not sure which one(s).

Re: Rich Command Shells

#10
If I might plug a rich command shell I'm developing: http://pigshell.com (Source at https://github.com/pigshell/pigshell)

It provides

- A shell for the web. Runs in the browser, pure client-side.

- File-like abstraction for URLs and other entities exposed by web APIs

- Unix-like style of composing commands using pipes.

- Visualization using HTML

For instance, cp -r /gdrive/ /home will backup the contents of your Google Drive to your desktop (see http://pigshell.com/v/0.6.2/doc/gdrive.html for details). Replace /home with /dropbox/, and the same command will back up GDrive to Dropbox. And so on.

While it is already useful, there is still some work, especially around hardening the file abstraction/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'll take ~2 months.

Post reply on HN