Tag Archives: edit

rename: The built-in filename sifting tool

Sorry for the one-day break; Thursdays are always a little bit hectic for me, and this being the last in the month was especially busy.

The bulk of util-linux is splashed across the previous post, but I have a few left over that I want to point out. rename is one of those, and at its best, rename is a quick and speedy tool for bulk renaming files. Here’s what it does, on a good day:

2014-09-26-6m47421-rename-01

That’s a classy solution for bulk renaming where the same string needs to be substituted out in each file. rename makes it (more or less) a cinch to swap date strings, replace extensions or even make mass insertions and deletions to file names … with a little added command-line kung fu.

rename‘s shortcomings — and you knew I was going to point some out — occasionally crop up, though:

2014-09-26-6m47421-rename-02

If you look closely, you’ll see that the last file name had its prefix changed, but not the extension. rename caught the first instance of “text,” but quit before it found the other.

rename also has very little in the way of error-checking. Once you send the command, the deed is done … and short of reversing your previous command, there is no preview-and-commit. And you must be cautious that your substitution doesn’t allow for files to be moved onto one another.

And it should probably go without saying that, unless you are a regex grand master, some of the more complex or subtle renaming that is possible with something like renameutils is lost on rename. Which isn’t to say it can’t be done, only to say that your success will depend on your proficiency. 😕

rename works though, and in minor substitutions it’s a breeze. And given its simplicity and straightforward arrangement, I can’t say too many bad things about it. Keep it in mind the next time you dump a couple hundred pictures off your digital camera, and need a system to order them. … 😯

mkfifo: Pipe panjandrum

I’m going to guess that you probably know what a pipe symbol does on most Linux systems — passes the output of one program to a second. It’s what allows you to do things like this

dmesg | grep ATA

and find local hard drives. Or gives me my topics for the day, with

ls vimwiki/ | shuf -n1

mkfifo is part of coreutils, and allows you to name a pipe, and reuse it over and over. It might sound odd, but it works in much the same way as the symbol.

mkfifo pipe

Now I have a file entry called “pipe” in my directory, marked with a “p” in the leftmost column.

kmandla@6m47421: ~$ ls -lha
prw-r--r--  1 kmandla users    0 Sep 21 07:42 pipe

Now I can jam something in that pipe, if I like.

kmandla@6m47421: ~$ ls vimwiki/ > pipe

And … apparently, nothing happens. My terminal is paused, somehow waiting for an action. The suspense is killing me. 🙄

Actually, until something collects the material in that pipe, it will pause there more or less indefinitely. So if I …

kmandla@6m47421: ~$ grep ch < pipe

The whole flood comes out, and we can all relax again. Crisis averted. 😐

2014-09-21-6m47421-mkfifo

It might seem rather pointless or irrelevant to name a pipe or even to make note of mkfifo for it. But you’ve already seen the subtlety in action, and maybe just didn’t think about it.

That first terminal emulator was paused, waiting for someone to unblock the pipe. A second terminal received the data and did something with it.

So what? So … not only can you jam a program’s output into a holding area, waiting for a recipient, but that also means you can pass data between terminals with a named pipe. So if you’re waiting for one program to end, you can send the output of another into stasis, until it’s ready.

And you can pass information between different programs running in different terminals, at virtual consoles, in and out of a multiplexer … possibly even between users or across distant machines if you’re clever. It’s not the best way to do those things, but it might work in a pinch. Experiment and see.

I know named pipes are not anything new, but little things like this are the reason I wanted to sift through coreutils again. If you need a better explanation of named pipes, and you don’t mind reaching back almost 20 years, Andy Vaught’s explanation from issue #44 of Linux Journal is a great starting point. Nice to see that things haven’t changed that much since ’97. … 😉

basename: What I had in mind

A while back, when I said I dumped coreutils back into The List because I thought there were still a few useful programs in there, I was thinking mostly of basename. So I’m kind of glad that shuf spat it out today.

I use basename a lot, although I can’t pin down any regular case that you might identify with. Here’s one that comes to mind though: Making sure the index page in my local wiki has all the programs included in the directory.

Occasionally I get sloppy and lose a title, or worse, have a file in the directory that doesn’t have a corresponding link in the index. That’s a problem because I can go months without knowing there’s an additional program in there.

I solve that by periodically dumping all the names of the files into an empty wiki page, and check links manually. vimwiki makes that fairly easy, since one press of the enter key will create a link, and the next will follow it. If the page is blank, it was a missing file, but if the file is there I can check that against my old list.

All this is terribly uninteresting. Let’s get to the good part. I use find to pluck out all the files from within /home/kmandla/vimwiki/ :

find . -type f

find naturally shows a preceding ./ for each file. I could fix that by adding -printf "%f\n" at the end, but vimwiki tacks .wiki on the end of each file, so I’d end up using basename anyway to get rid of that.

Ergo,

find . -type f -exec basename "{}" .wiki \;

In that case, basename trims off the leading path, and then the suffix .wiki from whatever it is given. The next step, which I won’t bother showing, is to dump all that into a separate file.

basename can cut off whatever you like from the end of a file, provided you predict it correctly. It’s a good way to trim file extensions, if you know what they are (if you don’t, you should be thinking about cut).

I have other uses for basename, and I can’t think of them right now. Perhaps in the future I’ll come back and add them on here, just for future reference. 🙂

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.

2014-08-01-lv-c5551-co

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.

2014-07-15-6m47421-cursetag

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.

2014-06-14-6m47421-v

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.

2014-05-26-jk7h5f1-tina

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