Tag Archives: edit

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. πŸ™‚

cursetag: So close, and yet so far

My holy grail application is a text-based music tag editor, something like — but not necessarily feature-identical — to EasyTag. I’ve probably harped on that point so much over the past almost-10-years that you’ve probably already tuned me out at this point.

cursetag got me so close today, I could almost taste it.


And then … well, you saw the gif. cursetag can read directories, recognize filetypes, arrange them in order, work a selection bar and then, at the moment of truth … splatters across the asphalt like an egg dropped from the window of a passing car.

I’m not enough of a programming guru to defunkify a floating point exception, although I have the feeling there’s some errant math in there. I won’t explain my logic, except I see a lot of errors reported elsewhere on the ‘net that link floating point exceptions to mathematical no-nos.

It’s a shame though: cursetag is barely a year old, if the github timestamps are accurate. We hardly knew ye.

I got the link to cursetag through AUR, and there is also a git version that I believe pulls in the same code, because both versions crash with similar skid marks.

Ah well. I can take a hint. I shall continue my eternal trudge across the desert, looking for that mystical fountain of curses-based audio tag editing. It’s a lonely life. …

v: Re-edit files quickly with vim

When you think about it, rupa‘s v is a rather obvious little tool.


v skims through your .viminfo file, plucks out the paths and names of files you recently edited, and then offers them back to you in a menu. Select one, and vim re-opens it for editing, no matter where you are in your tree.

Nothing fancy, and an idea that’s probably fairly easy to figure out. v adds a few bonus tweaks, allowing you to automatically jump to number N on the list, with v -N. Files are ordered from latest to oldest, meaning v -1 is always the last file you opened.

It’s also possible to filter the list of past files, or to include deleted files in the list.

v is simple and clever and straightforward, and if you work with vim exclusively but bounce around a lot, it’s likely to be useful.

Unfortunately — and there’s no practical way around this — I make a point of omitting any sort of vim history with set viminfo="" in my .vimrc. So unless I decide to change on that point, I’m afraid I personally won’t be adopting v any time soon. :/

tina: A funky little data arrangement tool

The home page for tina describes it as a “text-based personal information manager.” Which … I guess is true.


tina takes text data of any sort, and allows you to apply categories — much like you might do with a task organizer or perhaps a to-do list.

Controls are very vi-esque. Press o or SHIFT+O to add an item anywhere in your hierarchy, then press SHIFT+C to “categorize” it. There are navigation, cut, paste, search and other tools available, most of which follow the vi arrangement.

Where tina loses me is when categories themselves get categorized. Apparently it’s possible to categorize the category, then again and again and again.

And it’s also possible, although I’m not sure how I did it, to loop back from a category to the original data set, meaning there’s a circular structure that crops up. That might be just my whacked-out attempt to learn tina though. So if that’s weird for you, just ignore it. On the other hand, that might be useful.

tina saves its data as flat text files, and picking through those might give you some insight as to how tina is meant to be used.

I liked tina for being quick and light and colorful and easy to control, so long as vi controls aren’t foreign to you. It’s a little quirky in its behavior, but I can see where its arrangement and style might be useful, in certain situations. πŸ™‚

tidyhtml: Erasing your coding sins

Woe betide the uninitiated first arriving in the realm of HTML coding. Your work is shoddy, your style is crude, and your mismatched closing font tags belie the awful depths of your ignorance. Return to your hovel, peasant. Meditate on your sins and return when you have abandoned the wickedness of your ways.

Know ye first that this is foul. Slatternly. Slovenly.


Such petulance will be erased by repeatedly striking a rod across the palms. The HTML elite do not suffer such insolence.

This instead is the first step on the path of enlightenment:


Beauty. Elegance. Symmetry. Balance. Two-space indents. Only years of practice, asceticism and adherence to the principles of coding like a girl can produce such delicate, exquisite HTML.

The cultured elite can produce code of such perfection with ease. They do it daily. It is as natural for them as an eagle soaring on the wind.

For others, there are no shortcuts. Only toil and tedium. No easy path. No tricks or gimmi


What devilry is this?! Begone, you monstrosity! There are no short routes to achieving nirvana! Your sorcery will not go unpunished! The Yama kings gnash their teeth in anticipation of your arrival in the afterworld. πŸ‘Ώ


tee: More magic from coreutils

I have reached a point where I actively look forward to programs from coreutils, because I know they’re going to be good.

tee is no exception; like so much of what’s in coreutils, it is deceptively simple.


tee splits output two ways: once to STDOUT, and once to a file. So probably 90 percent of the time on this blog, when I’ve shown you something like this:

shuf -n1 /usr/share/dict/cracklib-small > test.txt ; cat test.txt

I could have done this instead:

shuf -n1 /usr/share/dict/cracklib-small | tee test.txt

and gotten both the file I was after and the output to show, without relying on two commands (and arguably abusing cat).

tee doesn’t just redirect to one file; you can list as many as you like.

kmandla@jk7h5f1 ~ $ echo "Test" | tee test-{01..10}.txt
kmandla@jk7h5f1 ~ $ ls test-*
test-01.txt  test-03.txt  test-05.txt  test-07.txt  test-09.txt
test-02.txt  test-04.txt  test-06.txt  test-08.txt  test-10.txt

Knowing that there will be identical output means you can also use tee to write to a file, but wrangle the output in some fashion. This is where you should be thinking about sort or sed or whatever, to create a record of the output, then an adjusted version.

tee takes flags for appending files rather than clobbering them, and as an added note, if you insert a hyphen as a file name, you’ll get double STDOUT. In other words,

kmandla@jk7h5f1 ~ $ echo "Test" | tee -

If you didn’t know about tee until now, it should open a few doors for you. Or at least, make a few things easier in your command-line adventures. πŸ˜‰

sort: Deserves better attention

A long time ago, when I was assembling The List, I thought to myself that I should save a little extra time and space for sort. Unfortunately it’s not going to work out, because of some time crunches I have in real life. And that’s a shame, because in no small sense, it’s a really great tool that saves me a lot of hassle.

Here’s an example. What’s your machine say if you ask it this?


If it’s anything like mine, and it probably is, you get a huge smattering of modules that are currently inserted into your kernel. That’s what it’s supposed to say.

Now try to pick out the ones that are interrelated. Not so easy, is it? If, for example, I want to see if the ath5k module was inserted when I jammed a PCMCIA wireless card in, sort comes to my rescue.

lsmod | sort

Yes, I know I could use grep, and in some cases I would. But modules tend to be interrelated, and sometimes it’s more useful to have a full list to scan, especially when troubleshooting.

sort can do a couple of interesting things. The -u flag will avoid doubling-up on entries, if you’re not interested in duplicates. The -h flag, which allows sorts by human-readable numeric values. How is that useful?

ls /etc -hs | sort -h

Now it’s useful. Even better, here’s the top five biggest files in a directory.

ls /etc -hs | sort -h -r | head -5

There are many ways to do that; that’s just one way to skin the proverbial cat.

sort gets a little cryptic when you’re not interested in sorting by the first character in a line, but it’s not impossible. Here’s a deliberately screwy text file, tab-separated, and we’re going to sort by the second column. 😯 Trust me. πŸ˜‰

kmandla@6m47421: ~$ for i in {1..10} ; do echo -e $(shuf -n 1 /usr/share/dict/cracklib-small )"\t"$(shuf -n 1 /usr/share/dict/cracklib-small ) >> test.txt ; done

kmandla@6m47421: ~$ cat test.txt | column -t
sial         nullstellensatz
galloped     codicil
pored        presence
measurer     lane
protective   ocean's
rapport      scotsmen
shrewd       sift
calculation  drafted
parklike     gimmicks
moslem       logo

The trick is to use the field separator and key flags to tell sort to look for a tab, and to sort by the first characters after that.

kmandla@6m47421: ~$ sort -t$'\t' -k2 test.txt | column -t
galloped     codicil
calculation  drafted
parklike     gimmicks
measurer     lane
moslem       logo
sial         nullstellensatz
protective   ocean's
pored        presence
rapport      scotsmen
shrewd       sift

The $'\t' represents our tab character, and the -k2 tells sort to do its magic on the second field it finds. Voila. That wasn’t so hard, was it?

I had a few other things I hoped to show with sort, but honestly, time these days is very short. Maybe one day we can come back and swap sort war stories. … πŸ˜€

P.S.: sort, like all great command line tools, is part of coreutils. πŸ˜‰

rev: skcik rof tsuJ

Little tools like rev are the best things ever.

kmandla@lv-r1fz6: ~$ echo Just for kicks | rev
skcik rof tsuJ

And that’s all it does. You can feed it a file as well, in case you want something more exotic than standard input will allow.

I know what you’re thinking; you’re thinking, “Why didn’t you tell me about that four days ago, when I could have sprung that on my unsuspecting co-worker, and routed everything through rev?!”

Aw, let’s not be mean, people. Life is difficult enough without untangling April Fools Day jokes. πŸ˜‰

rev, curiously enough, is part of util-linux. The question that naturally follows is, why in the world would that be part of util-linux? Perhaps they have a sense of humor that we lesser mortals are unaware of. πŸ˜‰

No fair leaving comments entirely in reverse. 😯

qpdf: Still more PDF wizardry

Just when you thought all your PDF options were expended, along comes qpdf to rattle your cage once more.

The home page uses “pdf-to-pdf” as a subtext for what qpdf does. And most of what qpdf does is just that: manhandling PDF files and getting the results you want, without distorting or smushing the content. (“Smush” is the scientific term.)

For example, reversing the order of pages in a pdf file.

kmandla@lv-r1fz6: ~/downloads$ qpdf --empty out.pdf --pages intro-linux.pdf z-1 --

--empty signifies a new file named “out.pdf,” --pages tells qpdf to wrangle pages, “intro-linux.pdf” is the source file and z-1 is pages 1 to the end, in reverse order.

qpdf is quite forgiving about page orders, sequences and even multiple sources. I haven’t tried every permutation, but I suspect you could do some real PDF wizardry with the freedom qpdf allows.

There are a lot more ideas in the qpdf documentation pages, which is so up to date that it’s timestamped in the future! πŸ˜‰ On a more serious note, the ins and outs of qdf’s power are all listed there, in precise detail.

It might take a little while to learn all the tricks qpdf makes available to you, but I have the feeling that if every other PDF gizmo fails you, qpdf will satisfy. πŸ˜‰

pdftk: All the others mixed together, and then some

I set apart pdftk from the rasher of other pdf-entitled tools for two reasons: One, because I already swept through Coherent PDF Tools a few months ago, and it seems fair to include another PDF suite; and two, because jojo and Antonio both suggested it.


It’s true, there is a metric ton of pdf-titled tools available, and a good four-fifths of them are true gifts to those living life at the console. (That last fifth … well, I’m sure they have their fans. πŸ™„ )

And yet, if you were to combine (almost) all of those into one suite, you would probably come up with something weakly resembling pdftk. And chances are you’d still have quite a few functions available in pdftk that hadn’t been tackled individually.

pdftk will handle the mundane tasks — like splitting, merging, rotating and “bursting” PDF files — but it can also flatten PDF forms into single files of form and data, encrypt at 40 or 128 bits with passwords, collate scanned pages in reverse order, preserve document IDs across input and output files, stamp pages a la watermarking, fill PDF forms from external files, and a lot — no, I mean a lot of other things.

Seeing something like pdftk in action makes me wish I had more use for PDF files on the whole. πŸ˜•

Best part is, it does this all in a clean and easy-to-understand fashion, without cryptic commands or unwieldy strings of flags. Bravo! πŸ˜€

Now … there’s no color. And there’s no real interface to speak of. I know those are minor shortcomings.

But I think jojo and Antonio were both right when they suggested pdftk; it’s obvious this is a tool done right.

Last note: pdftk is in AUR and Debian; I showed the Debian version mostly because it was going to take a looong time to build in Arch. I get so lazy sometimes. …