- tmux counts as a TUI UX. it is backed by ncurses (https://en.wikipedia.org/wiki/Ncurses)
- colors: it supports 256 colors, 24bit colors landed in 2.2 (but haven't used it)
- layouts: 1) supports splitting multiple command lines into "panes" which are resizable 2) supports custom layouts and arrangements for panes 3) you can "zoom" in on panes via `C-b z` 4) you can actually run other TUI applications within it
- interaction: 1) tmux also forks itself into a server in the background so you can de/re-attach your workspace 2) you can create and move between collections of panes, what tmux calls "windows" 3) command-based, so configuration via ~/.tmux.conf uses the same language as scripting 4) tmux can be scripted / remote controlled, you can even send-keys and copy the contents of panes
- help: the tmux manual is superb (https://www.freebsd.org/cgi/man.cgi?query=tmux)
Downsides are, I still get glitchy issues when using vim / unicode / colors in tmux panes which are difficult to diagnose. `reset` normally fixes it. It's been this way for years, and I don't want to even begin figuring out what the hell is happening because I'm using too many plugins. Considering starting from scratch. So if you get into tmux/vim/other CLI stuff, the simpler you keep your config, the better off you'll be.
(P.S. I am the author of The Tao of tmux, a book you can read free online)
There are many different teams within Heroku that need to provide interactions for developers via CLI whether its for dynos or data services. The guide was a way to codify building a consistent interaction that all product managers and engineers could follow. Disclaimer: I work for heroku.
Basically: Lisp supports idempotent type-based printing (print something in a form that can be read back to identify the same object -- basically unremarkable these days; consider python's __repr__ and __string__) as well as human-friendly printing.
The presentation system was remarkable in that when you printed an object it printed in the user-friendly form, but when the text was read back the IO system knew what the object was and so acted as if a machine-readable representation had been printed. It also used the type hierarchy to support mouse action in "ordinary" text, thus if you needed a SHAPE object, the mouse would highlight "Square at 4,4" and "Circle centred at 5,5, radius 7" as if it were #<CIRCLE 5,5, r=7>. In fact the "printed" representation need not be textual.
Also BSD4.1 sh is quite good one !:... and ^...^ etc were added.
As a side note, IIRC Emacs started out as Ciccarelli's TECO init file around '75/76 or so.
https://github.com/nvbn/thefuck
[TL;DR -- typo a command, type 'fuck', will run the command you should have run]
[0] https://www.youtube.com/watch?v=hJhZhLg3obk [1] https://bpython-interpreter.org/
- pymux (tmux clone): https://github.com/jonathanslenders/pymux/
- pyvim (vim clone): https://github.com/jonathanslenders/pyvim/
Lots of community-driven CLI tools with superb autocompletion:
- ptpython: http://github.com/jonathanslenders/ptpython/
- pgcli: http://pgcli.com/ + mycli: http://mycli.net/
- complete shells: xonsh (http://xon.sh/) + ergonomica (https://ergonomica.github.io/)
You can check it out by running "telnet mapscii.me"
The idea of enriching shell's UI is not new though, zsh and fish are both prior arts.
Gnus is a full-featured news, email & RSS reader (and others too maybe?). I've used it for most of my life.
Magit is a full-featured git UI, good enough that I don't bother using git from the command line anymore.
I'm constant midnight commander (linux/osx), FAR commander (windows) user. I'm so glad that it works flawlessly almost anywhere there is terminal support...
Edited: to use TUI instead of CLI
They're intuitive, interactive, come with embedded help, and use text mode to present a sophisticated, productive interface.
Also the Norton Guides were fantastic. TSRs [1], but with a TUI. You could get guides for C, dBASE, Clipper, Assembly, etc. I loved the TSR popup experience on DOS.
[1] Terminate and Stay Resident programs. They hooked into a keyboard interrupt to allow them to pop on a press of a hotkey.
[1] http://web.archive.org/web/20091011010412/http://www.vtsoft....
I've recently built an internal tool with inquirer and it was a really nice development and user experience. I haven't figured out the best way to test the interactions though.
termUI in go is also nice if you need graphing and viz for a dashboard like command line.
Inquirer is def the HTML inputs of the terminal but I got pretty far with it. My use case was Fairly Simple™ though. What other UI components do you think it's lacking?
- moc (Music on Console)
The configuration is also very flexible and includes a python API to write your own commands[1].
The only thing I'd personally ask for is if you offer an interactive interface, make sure you can execute the exact same commands on the plain CLI. Also (yeah, two things) support --help and --version (as well as -h and -v) out of the box.
Color, layouts (other than those required for readability), and other things just don't really matter as much, IMO.
I've previously used ncmpcpp [1] without any major complaints, although it's been a few years since then. It's an mpd [2] client written with ncurses.
On my personal servers I use goaccess [3] to analyze access logs. I remember being able to pick it up pretty quickly on my first try.
Only tangentially related, but you may find it useful to read the "Utility Conventions" [4] entry of The Open Group Base Specifications. I'd also suggest reading through the relevant entries under the "Program Behavior for All Programs" [5] section of GNU Coding Standards [6]. By following existing conventions (or even being aware they exist) you can sometimes make it easier for others to learn how to use your tool.
If you know JavaScript, you may consider writing your program with node. The blessed [7] library is a JavaScript reimplementation of ncurses, and there's even a react renderer [8]. This makes building the UI much easier than many of the alternatives I know. When you're ready to release, you can generate an executable [9] for easy deployment or publication. The biggest benefits of taking this approach are that it makes it very easy to achieve cross-platform support, and the barrier of entry is lower than many alternatives. The biggest caveats are that it'll be slower and much larger than if it had been written with C.
[1] http://rybczak.net/ncmpcpp/screenshots/
[4] http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_...
[5] https://www.gnu.org/prep/standards/html_node/Program-Behavio...
[6] https://www.gnu.org/prep/standards/html_node/index.html
[7] https://github.com/chjj/blessed
Another tui I like is for networkmanager. For whatever reason, nmtui always seems to work better than the gui frontends.
I think PyPy deserves a special mention -- it's been a few years since I built it, but the last time I did it drew the Mandelbrot set as a progress indicator.
- sub commands (and sub sub commands) provide a high level abstraction over the many different tools and features. The "toolkit" approach allows for easy expansion and refactoring of individual features, and is entirely pluggable by end users. It even provides tools to interface seamlessly (git rev-parse --parseopt; rev-parse is amazing and allows you to wrangle git types trivially). Git also doesn't care what language you use. It ships git subcommands in C, shell and perl, but you can use node, python, bash, go, whatever you like. Really great.
- git divides it's interface and features into porcelain (user facing) and plumbing (internal; used by porcelain implementations). This allows them to avoid breaking changes while providing new and exciting features. This is a great design choice and it's been copied extensively by many projects, but I've never seen it pulled off as well as git.
- git consistently reuses terms and objects (there have been some missteps over the years but the maintainers are very humble). Commit objects, refs, dates and times all work the same almost everywhere.
- git is extremely well documented, both in its man pages, online and within the tool itself. Help flags and interactive messages and descriptions and suggestions of what to do next. Have you ever performed an interactive rebase? Or resolved a merge commit? Or corrected a tracking branch? Just great stuff.
I know we love to hate on git here but let's just for a moment acknowledge this wonderful, powerful tool for something it does a great job at. Git cuts no corners, it's consistent and trustworthy, and a hallmark of modern day software engineering and UX.
There are other projects that interact with git and are really good: tig, for example. But git itself? Someone wrote a good paper about it already. "What's wrong with git?" was the title, I believe.
But git's user interface is inconsistent, has got weird error messages and confusing terminology with too many ways to do some things.
Good thing that it has quite decent manpages which explain these things thoroughly. The UI gets the job done but it sure isn't a great example of a well designed command line.
That said, you are right that understanding the git model helps a lot and for that, I recommend the "Getting Git" talk. https://vimeo.com/14629850
Can't quite put my finger on it, but some subtle differences seem to nudge the user towards more usable workflows than bare git.
(I mean when it's not an unpredictable sequence of commands that need to be passed to accomplish something outside of a regular workflow)
