ack: A grep for programmers

I am vastly undequalified to speak about ack, since the home page makes it abundantly clear that it’s a perl-based grep-like tool intended for programmers.

I am not a programmer, unless an emergency arises, and then there would be a better chance of success by employing a blind, one-armed, drunk monkey to smack at a keyboard for a few hours. I am quite confident of that.

But ack is on my list and I’d feel slightly guilty if I didn’t include it, since it was relayed to me by email from a reader (who asked to remain nameless). So here is my best attempt at ack, and the wizardry it reportedly can perform.


Let’s see. Color? Check. Easily readable output? Check. Searches entire tree? Check. Returns results with file and line number annotated? Check.

Well then, that’s my whole list.

As I understand it (because again, this is not a tool intended for the peons, like me) ack is supposedly faster or more complete than the traditional grep, and carries defaults specific to searching trees of source code files.

Not that grep can’t do those things. …


Only that ack supposedly does them better. Or at least that’s the impression I get from the Web site.

Like I said, I’m not a programmer so I don’t feel qualified to pick between the two. I have no preference for either, and I’m likely to stick with grep just because grep appears on my Arch system (and some others) by default.

I can be lazy that way. :roll:

alsaequal: Not omitted, by any means

I realized the other day that in 18 months of type-type-typing about this program or that, I only obliquely mentioned alsaequal once or twice.

I found alsaequal — or maybe alsaequal found me — years ago when I realized that for the unending trail of console music players, only one or two sported an onboard audio frequency equalizer. And for what I could tell, there wasn’t one in the wild.

I was wrong on that point, which is always a good thing.


alsaequal behaves much like a standard band frequency equalizer you might buy in any audio or department store. Left and right arrows navigate from band to band, and you can push levels up or down at the listed frequencies with the up and down arrows.

There are also preset levels for each band, accessible by pressing number keys.

alsaequal piggybacks off alsamixer, which is why you see the AlsaMixer title and version number in the screenshot above. If you eschew alsamixer … well, you’ll have to scrape around for a text-based frequency equalizer that will work with your audio subsystem. Let me know what you find.

There is also some specific setup that is required with alsaequal; your .asoundrc file will need attention and in my case, it looks like this:

ctl.equal {
type equal;

pcm.plugequal {
	type equal;
	slave.pcm "plug:dmix";
pcm.!default {
	type plug;
	slave.pcm plugequal;

Naturally, if you use different sound cards or if you have specific settings that need attention, you’d do better to look at the instructions on the home page.

As a final note, you start alsaequal with alsamixer -D equal — not some “alsaequal” binary. To that end, you might want to add alias alsaequal="alsamixer -D equal" to your bash profile and/or rc files. ;)

It pains me that, even at this late date, alsaequal is only in AUR for Arch, and as far as I can tell just hasn’t found its way into Debian. I can’t say why that is, but it seems an oversight. To the best of my knowledge, there is no audio-environment correction tool available in either distro that doesn’t require the bloated underpinnings of the Xorg dynasty, with the exception of this.

Of course, if I’m wrong on that point, I’d be happy to add another title to my list. … :)

recap: Everything about everything from everything, prepacked

I’ve cruised through enough system information tools over the past couple of years to recognize a few good ones and more than a few bad ones.

recap takes some of the better ones, mixes them together, and generates customizable reports.


That’s an example, where recap can pull in things like free, vmstat (think: procps), sar and a few other tools you might recognize off hand. Output goes to /var/log/recap/.

If I understand correctly, the author intended for recap to work at interval, along with something like cron. This makes sense, as a polling and logging tool that you can trace backward in time.

As a roundup of system data, recap makes good sense and has enough small customizable points to tweak that you can probably adjust it to your needs or wants.

I do feel obligated to mention though, that recap itself, for what I can see, is really only marshaling the efforts of outside tools, and consolidating their output. So it’s true, recap doesn’t seem to be doing any of the heavy lifting, but it does put together a nice summary.

And you might have a script already that does that for you. If not, chances are you could whip one up in a short amount of time.

On the other hand, recap seems to have done for you already. ;)

darkstat: Making an exception again

Last time I saw darkstat, I had some misgivings about including it among console-based software. I am having those same thoughts again, now.

2014-08-30-6m47421-darkstat-01 2014-08-30-6m47421-darkstat-02

The problem is, I have entertained a lot of programs in the past that lean more toward the graphical, even if they do a lot of their core work at the command line. Looking back, I probably shouldn’t have fudged with things like lilypond or even mplayer or inkscape, because in retrospect, they just aren’t intended to run at the console alone.

darkstat falls into the same bracket. It’s a fantastic network traffic monitor, has a great array of graphs and charts, but is really intended as a browser-based interface to your network.

True, it can dump your traffic in hex, to the console.


But that’s a rather humdrum task for a program that’s doing lovely things within X. If there is another mode or another way to see darkstat in action, other than pointing Firefox at, I haven’t found it.

Please don’t get me wrong: darkstat does a fantastic job and if I had a proper server running (god forbid) and needed to connect remotely and see what’s happening to it — within the last few minutes, few hours, days or even this month — darkstat would be at the top of the list.

But if I ever repeat this little adventure and cruise through console software again, darkstat won’t be included. No more exceptions. :|

asciiplanes: Akin to Battleship, but with a few issues

I have a game to show next, if I can call it that. asciiplanes is arguably a variation on the venerable Battleship game family, with a few small changes.


As you can probably see, the game works by “firing” into the grid, which reports back either a hit or a miss. Fire out the patterns of all the planes in the grid, and the game ends.

If I don’t sound too enthused about asciiplanes, it’s probably because I feel the game needs a little work.

For one thing, you might guess from the general layout and arrangement that asciiplanes is intended for … well, a strict ASCII environment. The name alone might suggest that, as well as the hyphen-and-pipe line drawing arrangement. And by default, asciiplanes fits neatly into an 80×25 terminal, scrolling just enough to vaguely hint at an “animated” game screen.

The problem is that asciiplanes uses special characters for successful guesses, which look like small ornate asterisks in a terminal emulator, but show up as nondescript blocks in a default virtual console. Rather defeats the purpose.

I have other complaints. The game options allow for a grid so small that asciiplanes can’t calculate where to place the targets. This means asciiplanes will hang if you give it a grid less than six squares on a side, but more than one plane.

In a larger sense, success is only determined by the number of shots and the time it takes to play through. There’s no consequence for a missed shot, as there is in the traditional Battleship rule set. Missing a shot in bs, for example, exposes you to your opponent’s volley.

This means asciiplanes just becomes a race to type through the grid as quickly as possible — a1, a2, a3 … — with the worst score being the square of the size of the grid and your worst typing speed. Short of playing asciiplanes while wearing a pair of gardening gloves, it just doesn’t hold that much challenge.

Oh, and there’s no color. Which always makes me sad. :(

I give asciiplanes mediocre marks for being functional, but without much depth. I can see where it might have its roots in a programming experiment or a classroom assignment, but it will need quite a bit more work — and perhaps a little more thought — to really stand as a “game.”

procinfo and friends: Become one with your hardware

Sorry about the delay, some real-life issues demanded attention, and couldn’t be avoided. As a way of making up for the lost time, here’s a three-in-one hardware information tool: procinfo.

2014-08-29-6m47421-procinfo 2014-08-29-6m47421-lsdev 2014-08-29-6m47421-sockinfo

procinfo appears as procinfo-ng on the home page and in Arch Linux, but just procinfo in Debian. Both packages install three tools: procinfo itself, lsdev and sockinfo.

sockinfo is probably the leanest of the three; you can see its output above, and the Arch version doesn’t even have a man page. sockinfo isn’t a bad program, but there are probably some more helpful socket analysis gizmos out there, so I doubt sockinfo sees much action.

lsdev is a step up, but only by a tiny bit. This will really get you closer to your hardware, right down to the IRQ and DMA. According to the man page, lsdev has no options, so what you see is what you’ll get. Depending on your system, of course. :)

That’s probably where my only complaint about lsdev arises: The output is a bit spattered. That might be a consequence of the hardware or the way the information is reported, but it’s difficult to see what is appearing in what column. Hopefully if I should ever need lsdev, I’ll have enough information at the start to intuitively pick apart lsdev‘s report.

procinfo is the real star of the show, and has enough options and visual style to make up for the shortcomings of either lsdev or sockinfo. Check out its man page, and then take it for a spin with procinfo -H -n2 or procinfo -H -n2 -d if you’re feeling crazy. You’ll get a nice, steady system-wide update that reflects the inner workings of your mysterious electronic doodad.

procinfo has a lot to tell and it’s worth trying for its meager footprint and clean encapsulation of everything from hard drives to memory usage. It doesn’t have color, but hey, you can’t have everything. If you did, where would you put it? ;)

minime: The 9.8K text editor

I have a huge list of text editors that could be added to my own dwindling list of programs, but I keep them separate because this site would just turn into The Text Editor of the Day Blog. And yours truly would suffer a nervous breakdown.

I do have one that I really like though: minime.


This one comes by way of an e-mail suggestion, and if I called it a minimalist editor, that would be an understatement. It’s not every day I see a new text editor, but it’s even more rare to see one in so little space.

The download page measures minime at only 9.7Kb, and it shows up at 9.8Kb in the version I cloned from the git address. Either way, that’s really small.

It might take a second to get used to minime, but I’ll give you a few hints. Use ALT+l to list the files in your directory. Start typing and you’re in insert mode. Highlight text with SHIFT+arrows, and if you have xsel installed, this is where your copy and paste functions appear. Copy in with ALT+W and paste out with CTRL+y.

Edit the minimerc file if those commands are a little awkward for you. They were for me.

As you might guess from the screenshot, most of minime’s functions are console commands interpreted on the run. So xsel is responsible for the copying and pasting. Pressing CTRL+n gives you a new file, courtesy of true. And you can see fmt at work there, for reformatting the text on screen.

I like that. I know that some of its functions are rudimentary, particularly when compared with behemoths like vim or emacs. But I think this has the potential to work as a sort of hybrid editor for the console. Imagine stacking up your favorite commands as CTRL key sequences. …

My only fear is that its reliance on xsel might hamstring it at the virtual console. Let me think about that one for a while. :|

Anyway, nice work for an under-10Kb program. And of course, note that you’ll need python to run minime, and xsel if you want those functions. Happy editing! :)