undistract-me: Quashing your ADHD

I fear this little utility might be usable only for a discrete set of fans. Technically speaking it’s a text-based application, but … well, I’ll let you take a look and see what you think.

In principle, it’s rather simple: undistract-me simply takes note if a shell command takes longer than 10 seconds to execute. If it does, it waits until the program finishes, then throws up the alert message you see in the screenshot above. Kind of cool, in an odd way.

Strictly speaking though, you’ll need all the underpinnings of a graphical desktop, plus whatever alert system is in use there, before you’ll get close to that kind of behavior. On my semi-graphical Arch system with just Openbox, I ended up adding gtk3, polkit, dconf, json-glib and a mess of themes and libraries before the git version was close to running.

So I don’t know if I’m being fair by including it. Don’t expect to suddenly plop this into place on your 400Mhz Celeron running screen, because you’re going to need a lot more to get close.

I won’t deny that I like the idea though, and if something comparable could be implemented in a text only environment, it might be worth trying. For my own part, I used to append long-running commands with aplay yoo-hoo.ogg so I would get an audible when something finished.

So in that way, I can sympathize. But unless you use a lot of terminal commands on a Linux Mint desktop and need some sort of blinky reminder when one finishes … well, like I said, it will probably only appeal to a slim range of fans.

hey: More anti-aliasing

After my less-than flattering assessments of betty, I got a note about hey. hey behaves, more or less, in the same fashion as betty, but perhaps with the addition of an “interactive mode.”

If you actually slogged through all the words I typed about betty, you’ll probably have a good guess at my opinion of hey. hey differs from betty on a few minor points, has its own list of identifiable commands, and might even handle scrambled word sequences better than betty.

But there’s not enough here to set apart hey from betty, and redeem either in the process. hey is doing much the same thing as betty — obfuscating some otherwise straightforward console commands (like the rename command, which would require much more typing than just mv) in the name of plain English.

hey has its own batch of idiosyncrasies, too. Just find file hey.py yields errors, unless the file name is enclosed in quotes. The command to download and compress the Google home page apparently worked satisfactorily, but yielded a file with a random name and no identifiable compression.

And while find me a restaurant did in fact open elinks to a list of restaurants in San Francisco, so did find me a laundromat. 🙄 Not to mention that I am not in San Francisco. 😐

I appreciate the efforts. hey and betty are about on par for me, but neither is the natural language interpreter it hopes to be. And neither is necessarily simplifying life at the console, so regardless of what you desire from betty or hey — whether it’s natural English comprehension or just an abbreviated console experience — I have the feeling you’ll walk away unsatisfied.

co: The command organizer

A couple of weeks ago, bm sounded like a good idea. This week, co sounds like a good one too. Where bm allows you to stash bookmarks and cue them quickly, co helps you build a database of particularly obtuse commands, tag them, annotate them, search them, filter them, and then recall them with only a few keypresses.

If co looks like a re-imagining of bash’s history tool, that’s understandable. A few important distinctions though:

• co doesn’t stash any commands until you tell it to, and then it only grabs the last thing you entered.
• When you tell it to save a command, you can add as many tags as you like, and a short “message” to remind you of the keyboard sorcery you performed.
• Once saved, you can list out the commands you saved, or filter that list by tag.
• You can perform a command again through co, by using its index number.

So instead of simply keeping a history of commands, co allows you to organize and manage the most useful ones.

As you can see above, it’s particularly helpful for long, complex commands that might otherwise require a lot of re-research to use again. co also has a rudimentary “interactive” mode, which allows you to step through your collection one line at a time, and even edit it on the fly.

One small note: There may come an odd situation where you ask co to save a command while you’re using more than one terminal. It’s possible (and I know it is, because it happened to me) that co will grab a command that was executed in another terminal, and save it instead of the one you just entered locally. Just so you know. 😐

co uses sqlite and ruby, and is not in Arch or Debian that I could find. I used gem install co in Arch to add it to my ~/.gems path; I’m sure one of you clever Internet heroes out there can build it properly for either of those distros, if you like it enough.

I really like co because it solves a dilemma for me: I hate programs that keep histories, but I do invent a lot of convoluted commands for esoteric situations.

co allows me to faithfully eradicate bash’s history at regular intervals, but still keep the command I use to generate sample text files filled with random words. 😕 Hey, that’s important stuff. 🙂

betty: Anti-aliasing

I have two applications within a theme today; one of them I talked about a month ago on some other random site, and the other is relatively new. Or it is to me, anyway.

First up is betty.

betty was steamrolling the Linux underbelly of the Internet for a while this summer, winning fans as a “Siri for the console.” Proponents suggested you could type just about any request of betty, and she would run the appropriate command and provide results. Rather than learning esoteric commands and flag sequences, betty could translate a request, pump it through the appropriate tool, and give you back an answer.

Which sounds like a fantastic idea, and I’m fully on board with betty … except as you can see above, it doesn’t quite work.

betty has preset commands she understands, most (all?) of which are listed on her home page. Deviate one character from those, and she’s lost.

Or worse, there are a few that supposedly work, that don’t. That’s what I hoped to show in the screenshot: that my typing skills were not to blame for betty’s empty replies.

I won’t harp too much on betty because I got most of my shots in last month, when fanboys hailed betty as The Golden Child of Linux and promised she would revolutionize life at the cursor. Suffice to say that betty doesn’t actually translate your commands, doesn’t parse context for a reply, and doesn’t tolerate deviation from her set list … hopefully.

Which means at best, betty works the opposite of an alias. Instead of just typing date +"%A", you’re typing in betty whats today, then sifting through her possible responses. If you hoped to save time typing, you didn’t.

And if you need to know the day of the week so frequently that you’d consider using betty for it, you’d do as well to use alias dow='date +"%A"', and do things the old-fashioned way.

But that’s enough for now. It will be a while before betty fulfills her promises, and becomes the natural language translator for the console. In that time, imagine how many traditional commands you could learn. … 😕

eval: Tells the shell what to do

Edit: Take a look at Michael’s explanation below. He seems to do a better job explaining eval than I did. 😐

I know this is an internal command, and I should probably wave it off as part of bash, but this one I use quite a lot. So I feel obligated to mention it.

eval interprets and expands a command before the shell can get its hands on it. That sounds cryptic, and in a way, it is.

But what that means is, eval will pass a command it finds elsewhere to the shell.

So let’s say, for example, you have a text file that tells feh what background image to use.

feh  --bg-scale '/home/kmandla/wallpaper/1919x1199-malaria.jpg'

I like to give my wallpaper wacky names. Yes, that is the contents of the file. If you have a .fehbg file on your computer, it might look something like that in there.

How do we pump that into bash, to get feh started and doing its wallpaper thing? eval, of course.

eval `cat .fehbg`

And what does it do? eval takes the results of cat .fehbg and passes it to the shell. So, the contents of .fehbg are dumped through to bash, and we get a malarial background on the desktop.

What’s another example? Remember back when slmenu was the newest thing on the block, and not just a common everyday piece of software? Well, if you recall, slmenu’s output was just the selected string … probably a name for a program, but maybe not. Maybe with some arguments.

And how did that program get sent through to the shell, and slmenu to finally do its job? With eval, of course.

scp: Simple is best

Technically speaking, scp is hardly a console application. This definitely falls in the realm of command-line “tool,” no more or less.

But it’s absolutely a godsend, sparing you the effort of setting up server-client network arrangements, if all you want to do is transfer a file or two.

In the past (and by that I mean years ago), I always went straight to nfs, mostly because I didn’t (and still don’t) have any Windows machines.

But I don’t bother doing that any more, if I can solve the arrangement with a simple scp command.

It’s hard to overstate the ease of using scp, which usually acts and reacts in the same way as the standard cp command.

And aside from demanding a password, it only requires that the remote machine have sshd working.

I know scp is nothing new, and it would be more surprising to find a system or distro that didn’t offer it, than to rehash it again.

But if you haven’t seen it work, you owe it to yourself to try. 🙂