conspy: Take command of your command line

I can think of plenty of ways to use conspy, but I can’t really think of one that shows it in action, except perhaps for this.

It might take a few seconds to see what conspy is doing there: That’s the vc2 login on my Arch system, reproduced exactly in a terminal emulator.

In other words, you get a faithful rendition of what’s in the virtual console, inside another terminal instance. This might remind you of something like screen -x, but it’s quite different.

It’s terribly clever, and I know I’ve used it in the past, even if I don’t think I made a note of it either here or on the old blog. Which is an oversight, and I should apologize.

conspy allows you to send keystrokes to a tty too, which is probably where it might come in most handy. So you could, in theory, send commands to a vc that is either inaccessible or remote. And pairing this with ssh means you probably have an extra layer of control.

There are some obvious question marks that arise. For one, you might wonder at the usefulness of conspy if either your terminal or your console is of dramatically different dimensions.

For what I’ve seen, conspy plays it safe by leaving excess space blank when you have it, and by arbitrarily cutting off the display when you don’t. I haven’t tried resetting or resizing a framebuffer with conspy, and I don’t know if you’d have much luck using conspy with a framebuffer emulator. I leave it to you to pursue those options.

I also notice some discrepancies in what a virtual console shows, and what conspy can display. Even just htop has a few oddball characters in conspy, that otherwise look fine in the tty.

And sometimes there’s a little lag between sending characters through conspy and their appearance on the screen. It could just be the side effect of working with a machine that is out-of-date by more than a decade, but it’s something I see.

None of those issues hamstrings conspy in the least though, since conspy allows you to effectively peer into a vc, or even issue commands through it, from far away. That kind of usefulness — and its apparent freedom from other tools that might let you do something similar, like screen — make it a valuable tool in its own right.

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

stty: Adjust the intricate details

I mentioned setterm almost a year ago, and in general that’s the tool you should rely on to adjust some virtual console capabilities. Things like color, cursor blink rate and so forth are handled by setterm. (Note: Not for terminal emulators. Emulators are handled elsewhere. 😉 )

stty is a little different, since it’s focused on the intricate line settings — baud rates, dimensions and so forth — for your console.

Ninety percent of what the stty man page describes is total gobbledygook to me. The remaining 10 percent is marginally useful. It does allow for some interesting acrobatics though, such as …

That’s mining-haze, which we’ll discuss another time. I used it here because it absolutely demands an 80×24 terminal screen — and what you see there is 110×38. 😯

I was able to get that punch-out effect by feeding this into the terminal beforehand:

stty cols 80 rows 24

and as you can see, the output arrangement is confined to that area — and more importantly, reported as those dimensions. Otherwise, mining-haze would serve me up a nastygram. 😦

Nothing earth-shattering, but it might save you a little trouble with picky software and unconventional terminal dimensions (think: tiling window managers).

stty can do a lot of other things, but like I said, the preponderance of what I saw in the man and info pages was intended for old-school terminal tweaking.

In that colors and timeouts and blink rates are all handled by setterm, it’s unlikely that I’ll rely on stty for anything but the exceedingly rare console setting. 😐

Oh, I almost forgot: the obligatory coreutils tagline. 😉

st and st: One for numbers, one for … numbers and letters?

I’ve got two programs named “st” on the list, which caused no end of confusion for about an hour today. Oddly, I can’t show much of either one.

The first one comes, yet again, from the suckless.org gang, because everything in the suckless stable starts with the letter S.

Just kidding. In this case st is a simple terminal and unfortunately every rendition — which is quite a few according to the AUR — failed to build for me. Most of those seemed to be from git, so maybe I just grabbed it at the wrong time.

I’m going to keep trying though, mostly because suckless.org usually does things right, and I plan on trying out some of their other toys too.

The other st is a miniature statistics tool, capable of skimming through numbers in a text file and providing some fundamental statistical information — a minimum, maximum, mean, standard deviation and a few other things.

I could build st but I’m not a perl pro, and it only gave me error messages when I tried to kick it into action. I have a feeling I hadn’t put all st’s little important parts in the right places.

The second st isn’t in AUR or Debian, so if you decide to try it out, there might be a little work involved. Not that a little work ever hurt anybody. … 😉

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