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. 😉

screen: The granddaddy of terminal multiplexers

I was for a very long time a faithful user of GNU screen.

That has mellowed somewhat over the past few years, partly because tmux — I must admit — is leaps and bounds beyond what screen can do, but also just because there are other options too.

Things like dvtm, or even twin, which both handle the concept of multiple-terminals-one-screen in their own fashion.

Any of those three can do … somewhat something similar to what screen does, and have probably all seen more improvements over the years than screen.

I hold no one responsible for screen’s slow spiral into staleness; in fact, if anything, that makes screen quite easy to figure out: There is plenty of discussion about screen and how it works … even if some of it isn’t flattering. 😯

It may be the ugly stepmother of terminal multiplexers, but you can’t deny that it does what it claims. And in the realm of console-based software, that alone is sometimes enough to get by. In my book, anyway. 🙄

Postscript, 2014-04-20: Wouldn’t you know it, only a day after whining about years without updates, this trickles down the pipe to my lowly Arch install.

You could knock me over with a feather. 😯 Ask and ye shall receive, apparently. 😕

screenify: A tetchy little tool

I have screenify on my list, and I think it’s a little out-of-order to speak of it before recapping screen proper. And since screenify strikes me as a little less than practical, I’ll just skim through it. There isn’t much to show anyway.

screenify should do much like what reptyr does — yank a running process into another terminal, but I haven’t met with much success.

Documentation is very scant for screenify. I got it to work once, basically following the crude steps in this zsh mailing list reply, but it hasn’t worked since then.

If I understand properly, these are the steps:

1. Start your process in one terminal.
2. Use CTRL+Z to pause it.
3. Then disown the process, which should free your terminal and if you’re lucky, show the PID of the free-spinning process. If not, check top or another tool.
4. Now from within screen, use screenify PID and you’ll get some rambling text along with a confirmation.
5. From yet another shell, issue kill -CONT PID, which should redirect the output into your screen session.

Like I said, it worked for me once, but never again. Just dumb luck, I guess.

And processes other than very simple, single-PID, non-console-applications don’t seem to follow through. In other words, bc, htop and alpine all refused to jump between terminals for me.

So I’m not sure what I did. It might be that it works better for you than me, but it will rely on screen in the first place (which I know is not the favorite terminal multiplexer these days) and gdb … at least it did for the Arch version. 🙄

If you get it working or can explain it better, please share. I have a feeling this is another one of those things that will do its job correctly under specific circumstances, and I don’t want to sell it short. 😕

reptyr: Pull the rug out from under your tty

I have tried to put together a gif of reptyr in action. I really wanted this to work, but I’m running aground of a few quirks. See if this makes sense:

reptyr should allow you to detach a process from a tty session and yoink it into another one … if I understand the underlying idea.

So with bc running on one tty, I can yank it to the other by feeding its PID to reptyr.

Essentially you get a similar effect as you might with screen or tmux, detaching and allowing the process to continue, but freeing up the original tty.

I can see where this would be very useful for applications you started without screen/tmux, then don’t want to end.

It’s not quite working perfectly for me though, but part of it was fixable. The home page mentions the need to do this, as root:

echo 0 > /proc/sys/kernel/yama/ptrace_scope

and without it, all I got were error messages.

In addition, as you can see in the gif, there seem to be some issues with typed text not showing up in the receiving terminal. I’ll look into that, and see if there’s a way around it.

But some applications, like htop, happily jumped from one terminal to another, without skipping a beat. mc jumped, but didn’t refresh the screen until I pressed a key. bc, as you can see, seemed to respond, but lost its echoed text. It still showed results, just not the text I entered.

Those small quirks aside, and from the perspective of pure function, this is definitely a keeper. For all the times I’ve ever had to quit one session and move to another, and start over, reptyr would have saved me the trouble.

A coveted K.Mandla gold smilie for reptyr: 😀

kibitz: A favorite of backseat drivers

Buried in a package called expect is a utility that seems to have a lot of potential: kibitz.

Or at least, it should have had some potential, when it started out in this world way back in 1994. 😯

(I know, that’s a lousy screenshot. I don’t know what I’d show if I did get kibitz running though. Stock photo of two people typing at computers? 🙄 )

If I understand it correctly, it should allow two users to piggyback in the same shell, watching each other type and offering help when necessary.

For me, it didn’t seem to want to work; I tried to kibitz from root to the kmandla account, but kept getting “write permission” messages.

I think I understand how it should work though, and I like the idea, generally speaking. Although two people typing in the same shell sounds like a recipe for a wheel war.

I did have better luck with screen -X though, many long years ago. If kibitz is still doing as it promised almost 20 years ago, it’s a worthy application no matter what I say. 😯