And one that the world has basically been through once already. But the first time it happened in the insular world of corporate and university mainframes.
WebAssembly is much better than JavaScript and XUL, which were/are both used to build browsers. Furthermore WebAssembly VMs are distinct entities from browsers.
I know you were joking, but the joke shows old biases that should just go away.
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.
I mean sure it's weird given the history but would it actually be that weird? If WA just becomes another VM like the JVM or LLVM that people can target it wouldn't surprise me to see someone port a web browser.
I'm oddly excited about command line tools lately. I've recently been porting all of our shell scripts to have color text output and Unicode status indicators (like a green checkmark for "OK" or red X for failure), when the terminal supports it (which, these days, is almost always). It just gives things a really polished feel that CLI tools don't always have.
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.
As of late i find myself thinking that the big DEs have been a massive distraction from what made _nix so potent. While Windows and Mac had largely tried to hide or distance themselves from the CLI in favor of the GUI, the way X11 is implemented allows CLI programs to use GUI for enhancements rather than replacements.
Blending CLI and GUI is not unique to X11; at least since .net was released on Windows this has been very easy, and it's not even that hard if you want to do this from the Win32 API.
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've recently been porting all of our shell scripts to have color text output and Unicode status indicators
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 just published the colorized logging library I am using (it's a rewrite of log4bash to support POSIX shells): https://github.com/swelljoe/slog/
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).
Just pushed out an asynchronous (cooperative, it requires the child process to touch a file to let the spinner know when to stop) Unicode and colorized progress spinner: https://github.com/swelljoe/spinner
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.
Curious if you have tried nurses at all and what you thought? Also, any useful resources for colorizing etc? I'm the sysadmin who writes the bland scripts...
I'm using tput from the ncurses package for setting colors in a terminal-aware way. You can do it with raw escape codes and most examples show it that way, but you can end up with different colors or non-functional colors on some operating systems (older macOS, among others). Using tput should smooth that out, assuming the terminal is reporting its capabilities and behavior correctly in termcap (as I understand it).
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
Note that the colors are somewhat arbitrary based on the palette your terminal is using. Most palettes I've seen are kinda close to right, though green often looks olive/yellowish, and others are really washed out, in the current crop of popular palettes (like Solarized). But, it does provide color. I linked the logging library I've been using in another comment, which includes POSIX-compatible examples of using colors like this (tested on recent-ish dash, bash, zsh, and ksh).
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.).
Just for fun. It makes me smile when I see stuff like that, so I'm gonna try to make my stuff more fun. My thinking is that as long as it falls back to something safe, it isn't hurting anyone.
htop is nice, sure, but not ctop levels of nice. Aside from the general pretty display and having network details ctop also has a really nice looking expanded view[1] that shows these over time with graphs.
A more UNIXy question is: why isn't there a generic tool that do nice and slick TUIs (textual user interfaces) so that htop, ntop, iotop, ctop and so on can all be implemented on top of it?
When I saw this post I was sure it was about yadutaf's project. The name collision is indeed unfortunate since the two projects basically do the same thing.
From reading the docs, it looks like ctop will connect to the local UNIX socket if there's no environment variable specifying a host, so you don't need to expose a TCP port to get this working.
Yes. Otherwise any process which can access the TCP port has full root access on the computer where Docker is installed. And root access to the entire Docker swarm cluster if swarm mode is enabled and the current node is acting as a manager.
Whether or not giving root access to a system performance tool is wise is left as an exercise to the reader.
Looks cool. I am trying to avoid manually installing software, especially on production machines. It makes it difficult to maintain and upgrade. Any plans for `apt` package?
I tried `go get -u github.com/bcicen/ctop` since I prefer uses the source, but there appear to be some syntax errors in master. Guess I could have added the tag, but I just used the binary.
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.
No port necessary, an interface for connecting other container/cluster systems is already defined. Feel free to open a feature request (https://github.com/bcicen/ctop/issues) for k8s to included as a connector in future releases.
(Not that I'm complaining; this is a needed tool.)