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.

neercs: Compiz at the console

Oh, you think I’m joking. You think K.Mandla has gone off the deep end, and is probably sitting in front of a busted-up Pentium M spinning a 3D desktop in ASCII against the framebuffer. Ho-ho, you laugh. Ha-ha, you chortle.

Well, chortle to your heart’s content. Because as it happens. …

Okay, so my attempt at a screenshot hasn’t done much to convince you, but it’s tough to time fbgrab right to get a good look at the animation effect. Install it yourself on your quad-core with 12Gb of RAM, demean yourself to switch to the framebuffer, and try it. It works better than you think.

It, of course, is neercs, a wacky play on the traditional terminal multiplexer that appears to have been cross-bred with either 3ddesk or the ghost of Compiz. Either way, it’s good fun.

I can coach you a little bit with neercs: You’ll start off with one “thumbnail” of a desktop along the bottom, and most of the key commands follow screen. Add another “desktop” with CTRL+A, C, then switch window layouts with CTRL+A, W, until you get the fullscreen model, meaning no layered or split windows.

Then CTRL+A, N, and the magic happens. You didn’t think it was possible. 😉

I didn’t either, so don’t feel bad. But believe it or not, you can indeed have a spinning cube desktop at the terminal. Yes, Virginia, there is a Santa Claus.

I am, as a matter of fact, playtesting it on a widescreen Pentium M against the framebuffer, specifically so I can see how it behaves in a virtual console. If you spin up neercs under X, probably you’ll be forced into an SDL-ish child window. But let’s face it, that’s not the same thing as a pure framebuffer environment. 😕

neercs seems to be holding its own, although I did swap out my regular 12-pitch Terminus font for the gigantamo sun12x22 just for that image. This screen is 1680×1050, and that’s painful to watch at 1.7Ghz. 😯 I don’t think I’ll be trying this with a sub-1Ghz machine.

neercs is in AUR as neercs-git, but doesn’t appear to be in Debian. Send your love letters (or hate mail) to the wizards of Caca Labs.

I think I’ll just let you tinker with neercs, and you can decide if it’s something you want to keep around. I can give it a lot of points for doing the impossible — blending Beryl with the blinker — and it has a solid color scheme and is on the whole quite entertaining.

Better yet: Imagine how your jealous your geek friends will be when they see your spinning desktop terminal. … 😎

ipbt: A better replay option

I mentioned a lot of terminal recorder options in the past, some good and some bad. ttyrec was one of those, and while it alone didn’t really impress, it is getting a small boost from ipbt.

You’ll have to look close at that image to see ipbt’s contribution. What otherwise just looks like a screenshot of a slightly mangled htop session is ipbt’s frame by frame controls and on-screen display.

ipbt adds just about everything you could want to ttyrec playback. Pause and start keys, frame advance, time compression, jump-to-frame and jump-to-end keys, and a bunch more. ipbt will even allow you to search through the text in the frame. It’s not exactly an Esper machine, but it’s clever.

Unfortunately, ipbt can’t do much about ttyrec’s overall quality, and the frame above is a good example. ipbt allows you to step through those recordings and perform a heady acrobatics with them, but I’ve seen very little from ttyrec that wasn’t mangled to start with. So perhaps ipbt is just lipstick on a pig.

Regardless, someone put a lot of effort and time into ipbt and it does make the otherwise less-than-thrilling ttyrec into a proper and usable recording and playback tool. It’s a shame it can’t capture correctly though. 😐

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

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

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.