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:

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:

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

dirname: That slash-mark filter you always wanted

I should probably mention dirname out of coreutils today, since it effectively reverses what we saw the other day with basename. This is easier to show than explain.

kmandla@6m47421: /usr/share/pixmaps$ dirname /usr/share/pixmaps
/usr/share

dirname strips away the directory and shows only the path up to the final folder. In the example it was the current directory — you get the same results from dirname $(pwd) — but you can feed it any path (or more than one), so it’s not correct to say “your current directory.”

If you feed dirname a path and file name, you get the path of to the file, which is where dirname becomes useful.

kmandla@6m47421: ~$ dirname /home/kmandla/downloads/list.html.txt 
/home/kmandla/downloads

Now you can effectively strip away the filename from a string, and leave only the path to it.

kmandla@6m47421: ~$ dirname $(find /usr/share/pixmaps/ -type f -iname "*png") | sort -u
/usr/share/pixmaps
/usr/share/pixmaps/pidgin
/usr/share/pixmaps/pidgin/animations/16
/usr/share/pixmaps/pidgin/buttons
...

So I know I have png files somewhere inside /usr/share/pixmaps, /usr/share/pixmaps/pidgin, and so on.

Now comes the strange part: If you give dirname a file in your current path, you get a lonesome dot.

kmandla@6m47421: ~$ dirname .bashrc 
.

This strikes me as odd behavior, since this is also dirname‘s response:

kmandla@6m47421: ~$ dirname /home/kmandla/.bashrc 
/home/kmandla

The man page comes to the rescue this time, and after reading that, I would hazard to guess that dirname is just traipsing along the string until it reaches the last slash, then dumping everything before that to STDOUT. No slashes means … a dot. 😕

And my suspicions are confirmed with this:

kmandla@6m47421: ~$ dirname this/is/a/test
this/is/a

So basically dirname is a filter for slash marks, and whether or not that represents an actual folder tree on your system is … moot. 🙄

dirname is useful in the same way as basename, but again, I can’t give you any tried-and-true uses that aren’t specific to my own real-life adventures. I leave it to you to come up with something earth-shattering and life-changing to use with dirname. It’s not an impossibility, even if it is just a slash-mark filter. … 😉

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

rntools: An unexpected find

I have an application called “rn” in my list but I couldn’t find that anywhere. But I did find something called rntools, while I was digging around.

rntools is probably the safest, least unpredictable renaming tool I’ve seen so far. Even qmv, out of renameutils, has a few quirks that rntools manages to avoid.

For one thing, although rntools is menu-driven, there are some flag options. This is a bonus, since it means you can avoid long, boring command sequences with the menu mode, but also inject it into a script or give it quick commands to complete.

The menus cover a lot of possibilities, from simple case switches to complex search-and-replaces. And after you’ve made your selection and provided it with the info it needs, rntools will double-check that you’re getting the results you want before proceeding.

So you get the opportunity to back out, or reject your changes altogether. Nice touch.

All that is fine and dandy, but I do have a couple of small suggestions.

First of all, it’s no trick to make rntools crash, perhaps most easily by forcing it to rename files to some illegal sequence. I caused havoc just by renaming my data files to something starting with a hyphen, which the underlying rename process took to be a command-line flag.

Second, a couple of the options are a little too cautious. As you can see above, the command to cut characters out of a name asked me to confirm the title each time for each file. That’s not saving me any time if I have a hundred files to plod through, one by one.

On the whole though, rntools is a good option for safer, more meticulous file renaming on a large-scale basis. And hey, it’s got color. Can’t go wrong with that. 😉

P.S.: I only saw rntools in AUR, so Debian users might have to build it on their own. It shouldn’t be too much of a challenge. 😉