(Not that I'm complaining; this is a needed tool.)

I know you were joking, but the joke shows old biases that should just go away.

Obligatory reference: https://www.youtube.com/watch?v=9nazm3_OXac

I think it is going to be very cool to see exactly how powerful and flexible this sort thing will become - how long til you demo a new tool by launching a linux container built on a webassembly vm that allows you to experiment with a new app with zero deploy effort.

An alternative possible today: `docker run -it rockstar:testbed newtool`

Even older, Java Web Start provided this in 2001.

I've used tools like dialog, in the past, but I've never really been a big fan; they seem like the worst of both worlds. It has the low-information density and high interaction requirements of a GUI, without actually looking really cool in the way a GUI can.

That's my long-winded way of saying, I also really like the way this looks, and I'm totally stealing some of the visual ideas here for my own tools.

There are also a few windows "command line" applications when invoked with bad parameters will show MsgBox or Dialog boxes instead of writing errors to the console, which is super irritating when dealing with older versions of those tools in scripts.

That said, the bog standard windows command line environment is so awful that it makes doing anything useful with this blended UI less than ideal :/

That is a image viewer that can be operated from the command line but that then produce a GUI window (or windows) that can be manipulated by mouse and keyboard.

It has also various options for displaying image properties in the terminal.

Meaning that it could be leveraged along with existing _nix CLI tools to fine images in a large directory (or even directory tree) and then display the result, all by piping commands together.

I kinda have a similar intent of revamping user UI and user interaction of my personal scripts so I would appreciate some insights. Do you have any specific tips, helper functions or code snippets you can point me to? Do you just copy, paste and modify code snippets around when needed or have a clearly defined and reusable functions for printing, listing, displaying, prompting things etc.?

I also have a few other functions I'll be wrapping up into a utility function library, once I make them all work nicely across all of the shells I'd like to support.

I'm mostly working from functions I wrote years ago and haven't touched in the interim (except to make them work with POSIX/dash, when Ubuntu switched /bin/sh from bash for 6.06).

I wouldn't call this one production ready yet. It needs to be in a function and needs to get its variables scoped and such. But, I was curious to see if a POSIX shell script could be coaxed into doing those super fun spinner designs with goofy shit like happy faces or peace signs or the like. And, it turns out you can. Long code points don't work, anywhere that I tried, yet...so my dream of a clock face with a moving hand is not yet possible. But, some day, it'll happen.

For example, I use the following to setup colors for printing log output to the display:

    readonly LOG_DEFAULT_COLOR=$(tput sgr0) # Clear colors
    readonly LOG_ERROR_COLOR=$(tput setaf 1) # Red
    readonly LOG_INFO_COLOR=$(tput sgr 0) # White
    readonly LOG_SUCCESS_COLOR=$(tput setaf 2) # Green
    readonly LOG_WARN_COLOR=$(tput setaf 3) # Yellow
    readonly LOG_DEBUG_COLOR=$(tput setaf 4) # Blue

As soon as I figure out how to reliably detect Unicode in a terminal in a POSIX compatible script, I'll publish some other utility functions that use Unicode.

The resources are pretty spread out. The tput manpage is utterly opaque, to me, as it covers a bunch of stuff that isn't relevant to "make it pretty" scripting. Mostly I've just been googling a lot. Unfortunately, the vast majority of examples on the web are for bash (also bash is easier to google for), so I'm having to trial-and-error my way to a POSIX compatible implementation.

I don't know of any way to use sh directly with ncurses itself, though there are programs like whiptail and dialog that'll harness some ncurses power for your scripts. I guess they're OK, but as I mentioned in another comment, I find dialog TUIs to be clunky. I don't want a windowing style GUI that happens to work in the CLI; I want a CLI that is traditional "run a command, get some output", but the "output" part just looks nicer, and is maybe animated in some way if it makes sense (a spinner or progress bar, e.g.).

Did you mean to say ncurses ? Or is there some new "nurses" thing that I don't know about ?

I am curious what is the upside of unicode vs plain ascii in this context?

[1] https://github.com/bcicen/ctop/blob/master/_docs/expanded.md

http://hisham.hm/htop/index.php?page=screenshots

Some of them show both 1.0 graphs and the new, unicode based ones from 2.0.

However they are still not per process. And there are no network statistics.

[1] https://github.com/elw00d/consoleframework

https://github.com/gizak/termui

https://github.com/gizak/termui

https://github.com/nsf/termbox

But they could all probably be a bit better.

  C:\ctop> type Dockerfile
  from buildpack-deps:jessie
  run curl -fsSL https://github.com/bcicen/ctop/releases/download/v0.4/ctop-0.4-linux-amd64 -o ctop && chmod +x ctop
  cmd ./ctop
  C:\ctop> docker build -t ctop .
  C:\ctop> docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock ctop

Too bad that the name collides with the Ubuntu package ctop which installs https://github.com/yadutaf/ctop

Whether or not giving root access to a system performance tool is wise is left as an exercise to the reader.

You should check if `fpm` has support for making packages for go projects (It should. It supports Python and Ruby). Then it should be simply to create packages, sign them and put them on your company repo.

I've worked at shops where we do this and even run update scripts to tell us when new versions are available and kick of the fpm build process.

https://github.com/lirantal/dockly