blessed-contrib: A well-earned clamor

I’ve gotten three or four links to blessed-contrib in the past two weeks; thanks for the tips. Usually a quick flurry of attention like that means two things — first, that it appeared on a forum or in a news post somewhere, and second, that it probably is very good.

It seems the clamor is well-earned this time. Here’s the “example” arrangement.

The animation is missing there, which is a shame, because just about all of those little widgets have some sort of activity going. If you want to see the full effect, try the animated image on the Github page.

I haven’t said what blessed-contrib is, because it’s what you make it. This is a tool toward other things, and not so much an application on its own. So if you were expecting those little doo-dads to dial you into NORAD a la WarGames, it’s not going to happen … unless you can make it happen. 😯

It’s fun to tinker with blessed-contrib, but you will need a degree of programming ability and access to a few other ancillary projects — some of which, like spark, we’ve seen here.

I also feel obligated to mention that the effect was somewhat lost in a virtual console (on my Arch machine, anyway) because, as is wont to happen, some of the text shapes used in the graphs were inaccessible to the screen font. I’m sure there are ways to specify the exact characters used in those graphs, so you might want to keep that in mind if you decide to pull blessed-contrib into your next killer app for the console.

From what I gather, blessed-contrib is fairly new, and I see edits as recently as a few days ago. Ergo, this is not in Debian or Arch/AUR. If you want to give it a spin, I installed python-blessed out of AUR and nodejs from community, then followed the quick install instructions on the home page to get as far as the demonstration panel.

If you come up with something entertaining, by all means share. 😉

vlock: The simplest screensaver I know

I made a big stink a few weeks ago about some less-than-ideal terminal screensaver utilities, and I suppose, technically speaking, I omitted one.

Hiding down in the bowels of kbd in Arch (but living the high life in its own package in Debian) is vlock, and yeah, I suppose you could call it a screensaver. A very simple one.

vlock seizes (but doesn’t clear, oddly) the terminal you’re using, and demands a password before it will release it. A useful tool if you’re in an office and need to go to the bathroom, I suppose.

Outside of an option to lock all the virtual terminals, vlock doesn’t have a lot of flags to worry about. And by corollary, the man page is really just a man pamphlet.

Of course, as a practical screensaver it’s not much better than termsaver, or terminal-screensaver, and doesn’t fulfill the two problems I set out three weeks ago. Nobody’s perfect.

And given that most terminal multiplexers have their own locking mechanisms, it may be that there’s not much call for vlock. Be that as it may, you have the option available to you. 😉

termrec, ttyrec, tty2gif and others: Pretty as a picture

I realize now, well after digging deep into the T section, that I should have broken apart a lot of the programs listed here and clumped them together in megaposts, like I did with 2048.c.

I’m going to do that again now with a series of applications that are intended to convert terminal output into a replayable format, and beyond. Knowing that, you might correctly infer that there’s not much to show. You would be correct. In other words, no screenshots. 😦

Recording what happens in the terminal is not new. If you remember script, the granddaddy of terminal recorders, you’ll know that this idea has been around for decades, and there’s nothing new in piping the output of your terminal screen (emulated or not) into a recorded session. The novelty comes in the variety of tools that will do it for you.

I intentionally skipped over one of these programs — termrec — a week or two ago. I’ll take care of that one today, and I also have nh_recorder, ttyrec, ttygif and tty2gif, plus a bonus at the end and an online solution to mention. For each one I’ll try to give a quick rundown on the high points and low points, and my overall impression.

Let’s go.

nh_recorder:

Pros: Very light, very transparent. Could be good for extreme cases where nothing else seems to function, or over specific network connections. Cons: Only dumps to a file; needs its counterpart, nh_player, to replay. No practical control outside editing the code. Seems to only update a line at a time. I.e, no real animation effects, only periodic line-by-line refreshes.

Overall: This might be just a primitive tool intended for use with old versions of NetHack. It works, even if it’s not really practical.

ttyrec

Pros: Supports remote sessions. Can start an application directly, instead of spawning a subshell (a la script). Can append existing recordings. Has playback and timer tools. Cons: Clips the terminal size, which means you may end up with large empty areas if you record ncurses applications. Only sends output to its own format. No compression options.

Overall: This is a step up from nh_recorder, but it’s frightening that it slices away at the terminal area and leaves large black swaths where your application should be. I hope that was something I did wrong. Regardless, it lacks some of the features that the upcoming applications have.

ttygif

Pros: Converts ttyrec format files into animated gifs, by playing back ttyrec files and using imagemagick‘s import command on them. Cons: Somewhat haphazard in its delivery. Two-step process; ttygif makes a slew of specifically named images, then relies on an included shell script to concatenate them. Final product should be a recording of the terminal session, in gif format. Relies on imagemagick.

Overall: Just too spattered for my liking. Even short recordings create a mess in your directory. The only time I can see where this would be a good approach is if I needed to edit out specific frames of a recording, and even then it would be a chore. Conceivably this could allow some control over frame quality and delay though.

termrec

Pros: Automatic compression. Support for ncurses applications. Compatible with ttyrec. Option to append recordings. Will save in several formats. Can jump straight into an application, instead of spawning an additonal shell. Cons: Some screen corruption in playback of ncurses applications. Terminal size clipped. No automatic conversion to gifs.

Overall: This is step up from ttyrec, but it still seems to suffer the two main faults of its predecessor: I’ve seen a lot of corrupted playback, especially with full-screen console applications. And clipping the available recording area makes it only marginally useful to me.

tty2gif

Pros: One tool for the entire process — record, save, and convert. Control over filenames in both the saving and conversion process. Can replay its own binary save files. Automatic conversion to gif, if desired. Cons: Sometimes tricky to play back a file without overwriting it. Relies on imagemagick. No automatic compression. No control over image format, or flags passed to imagemagick. Can eat memory like a pig — I’ve seen it gobble a gigabyte for a 20-second 80×24 recording. Sometimes corrupts the output image, but only very rarely.

Overall: This is the one I use, mostly because it will record the entire terminal area, and generally it doesn’t garble the end result. I have accidentally overwritten a recording while trying to play it back, but the conversion to gif is convenient and thus far without fault (the one time it did create gobbledygook was probably my error). With a few small improvements, this could be the clear winner. If it doesn’t get a handle on memory consumption, it’s not going anywhere though.

The gifs you’ve seen over the past week or so were made with tty2gif, and I’ve more or less implanted it into my system after tinkering with the other four. It’s possible that there are others, but between script and these others, you should be able to find one you prefer.

Now a bonus goodie: termcast

termcast lets you broadcast terminal sessions live, a la twitch.tv or some other streaming video sites. I can’t say that I built up an entire system to show my own terminal sessions — the tools are there for that — but I did watch a game or two of nethack that someone else was playing.

termcast relies on ttyrec for broadcast, but you can watch a game with only telnet. I’m not sure if the same issues with corruption or terminal size persist through termcast. I know I did see some garble in the games I watched, but I assumed that was from differences in terminal environments or something related to telnet.

And as promised, an online solution: showterm.io

I got a link a long time ago to showterm.io but forgot what the name was, making it rather tricky to hunt down. James T. sent me a working link a few weeks ago, so I’ll credit him with the catch.

The showterm client installs through gem or by straightaway downloading the binary from the home page. Recording and uploading a session provides you with a link, which you can use to view the session or share with others.

If I remember correctly, I was able to upload a recording from an X-less machine, but it probably goes without saying that you’ll need some sort of graphical environment to view the link. I tried this quite a while ago, but I seem to remember elinks throwing its hands up in frustration when I fed it the showterm.io page.

---

I think that’s all for now. Taking these six or seven applications and loading them all on one post has taken a nice chunk out of my list, especially since there’s nothing in particular I can show for them, one by one. 😉

termsaver and terminal-screensaver: Peas in a pod

I’m going to lump together two programs again, this time because they more or less do the same thing, and because if either one is doing their job, I won’t really be able to show them in action. Also because, given the chance, they might work well together.

Both termsaver and terminal-screensaver work as “screensavers” for your terminal, as you might have guessed by their names. 🙄 They each take a slightly different approach to the issue though.

A long time ago, before I rounded up my own esoteric solution to the screensaver for the console, it was clear that two problems were at work simultaneously: First, something has to sit back and watch your terminal activity and hijack it when nothing has been happening. Second, something has to restore it cleanly when you return.

The obvious solution to that is to have some sort of daemon diligently watching your terminal session, and spawning a third program when your timeout is triggered. And of course, end that program and restore your session at the press of a key.

That’s the approach terminal-screensaver takes, and it does an admirable job of doing so. I first ran across terminal-screensaver a couple of years ago, and for the most part, it worked as promised. The author has a YouTube video of terminal-screensaver at work, if you are one of those visual learners. 😉

As I see it in my puny little nonprogrammer brain, terminal-screensaver relies on your .bashrc (or .*shrc) to trigger a daemon when you start a terminal. That daemon sits and watches your activity, and kicks in the screensaver of your choice — the default is cmatrix, but there are lots of others that could work — when it senses you’ve gone to the refrigerator.

terminal-screensaver can be a little tricky to configure; you have to get its configuration file, the daemon’s configuration file, the working directory for the daemon, your .bashrc and your $PATH all living together under one roof … which sometimes isn’t easy.

When it’s done right, it does work as promised. When it isn’t done right, you get a lot of strange messages spattered across the screen, nothing ever commandeers your terminal, and even when it does, getting it back can be a trick. So at least you’ll know if you don’t get it right. 😉

termsaver, by contrast, expects you to trigger it directly, before you walk to the refrigerator. Here again, is the obligatory video supplied by the developers.

termsaver comes with an array of built-in screensavers, the bulk of which pull text from external sites — the list is in the --help message — and send them to the screen, typewriter-style. There are also the obligatory clock and zipping dot modes, as well as jumping random words.

A small glitch: termsaver didn’t think to set the cursor behavior, and my XP-wannabe terminal style uses a solid block cursor, which is visible as it jumps around the screen. That too is a small note, if anyone sees it.

My biggest challenge with termsaver was the fact that it doesn’t really … work like a screensaver. By that I mean that termsaver doesn’t approach the original two challenges I mentioned.

Without some external program — and I daresay terminal-screensaver would work in this case — to handle the timeout and restore issues, termsaver is just a pack of terminal gimmicks wrapped up in one program.

You can start termsaver as you get up from your desk, and you might even go crazy and set up a one-key trigger to kick it into action when the refrigerator summons you.

But it’s not watching your lack of input, not counting out the idle seconds, and so in my mind, it’s not really solving the problems of a proper, classical, terminal screensaver utility. 😦

After looking at both of these, I still think using screen’s built-in idle function or tmux’s analogue is a better way. tmux and screen can both solve the console screensaver challenge (which I see as a step forward when compared to termsaver), and they both require only a few lines of configuration (which is less than terminal-screensaver needed).

On the other hand, if you’re not interested in using a multiplexer while you work at the command line, perhaps one of these — or both together — will push you a small bit closer to text-only nirvana. 😉

splitvt: Under the most dire of circumstances

Between tmux and screen, there’s really not much space for upstart splitscreen console tools, unless they can do things really, really well.

splitvt is really, really not that tool.

That’s the prettiest, cleanest results I could get from splitvt, although I admit I hardly tried beyond the first few console tools that came to mind.

Yes, splitvt can run two console apps in the same frame. And yes, you can spin it up with two very different applications, and get both of them going with reasonable fidelity.

But anything outside of the simplest, most basic output gets sickeningly mangled, like a ten-car horrorcrash, or a drunken prom queen turned loose on a makeup counter in an abandoned department store.

htop came out looking like Van Gogh’s The Starry Night. Midnight Commander was a gob of scrambled eggs sliding off a plate. Don’t even ask me about elinks. I don’t like to think about it. 😯 😥

And splitvt is clearly intended for non-interactive programs. I find splitvt traps you in the upper bracket, meaning any input intended for the lower half is effectively ignored.

There’s some sort of “command mode” for splitvt, which I found by accident. If you hit CTRL+O and then enter a question mark, you’ll get a brief list of commands. From there you can adjust the property boundary, copy and paste (supposedly) or lock the screen. Other tips are listed.

But I’ve seen enough. I know it’s not fair to pick on a program that’s beyond its freshness date, and it may be that when splitvt was in its prime, it was neck-and-neck with the best that screen or tmux could offer.

But these days, with tmux leading the pack featurewise, and screen coming out of retirement to do battle with the usurper … splitvt is easy to dismiss. Try it, but only under the most dire of circumstances. 😐

script: That terminal session recorder you always wanted

I wasn’t going to include script in these little adventures, but owe a day’s worth of programs after skipping a day yesterday, and script isn’t terribly difficult to cover.

It is difficult to show though, since you don’t really have any guarantee that what I’m doing is really working, if I can only show a static image. But script is part of util-linux, and it’s been around apparently since 3.0BSD, which translates to around 1979 and the same time the users command was added. So it’s probably available to you. 😯

Try this at home then, and see if you are as astounded as I was when I first saw it happen.

script -t 2> man.timing -a man.session

You should get an acknowledgement that says, “Script started, file is man.session”. Next,

man script

You can peruse that for a little bit. When you’re done, exit your man page reader and enter this:

exit

And the output is “Script done, file is man.session”.

So what good is that? Well, do this next:

scriptreplay man.timing man.session

And you get a perfectly timed session replayed as you like. And yes, it works with ncurses and fullscreen apps, and as far as I can tell, there doesn’t seem to be a limit on terminal dimensions (except perhaps on replay … I don’t expect it can cram a huge recording into a tiny window frame).

It’s funny, there are a baker’s dozen of console recording tools out there in the world, some working, some not — some even hotwired into cloud services and offering automatic uploads and infinite replays. 😐

I’m sure they all are fine and dandy. And yet, from the depths of util-linux comes a simple, straightforward terminal recorder that’s been around … well, since forever.

dtach: Beauty in sparsity

I have known about dtach for a long time. I’ve used dtach briefly to free virtual console space.

But dtach is such a slim tool and has such a narrow focus that I wonder what it could offer in the stead of either screen or tmux.

(Danger: 1024×768 gif.)

That’s about all dtach does — detaches from a terminal and reattaches soon after. I suppose there’s not much more to ask of it; people that I know who use dtach want that function and that function only.

On the other hand, I do like that I can name a socket, which makes it easy to reattach to one later.

If you like the idea of detaching from a terminal, but don’t want the stoic classicism of screen or the dynamic complexity of tmux, dtach might be an answer.

One quick final note: I mentioned dtach when I mentioned dvtm. Oddly, I see these two working together quite nicely. It might be that I just was introduced to them both at the same time. Of course, you could substitute anything you wanted. …

dvtm: Sharp, clean and quick

I had to look back through the old blog to see how far back I had first met dvtm.

I know this probably doesn’t fall into the “console application” category, but I’d be leaving out some great stuff if I didn’t include it.

For a console-based “window manager,” dvtm is about all you need. It differs slightly from things like tmux or screen … in ways I can’t quite describe.

As I understand it, dvtm borrows some code from the suckless project‘s excellent dvm window manager. So if you are used to one, you’ll probably know the other.

I don’t use dvtm much, but I plan to more in the future. I may have to dig around in the code though, and customize it a little. The default keys are less than to my liking.

By the way, if you want it to behave like screen or tmux and allow detachment, dtach is your answer. More on that next.

Bonus: Remembering 1987

I know you Amiganauts are still out there, cuddling up to your toasters and purring about Workbench.

Let’s see how many of you are paying attention. This should bring some of you out into the sunlight:

 

If you remember 1987 and arguably one of the finest computers ever made, you might want to tickle your sense of nostalgia with amigashell.

To be honest, there isn’t much to amigashell except perhaps to set the font on your framebuffer and adjust the color scheme and cursor slightly. Oh, and the workbench status bar. Okay, and a ticking clock. And. …

So if it doesn’t work for you, don’t feel bad. There are other ways to get that Amiga sensation again. … 😉

P.S.: Framebuffer only, friends. 😈