Tag Archives: search

alot: With notmuch help involved, and little more

Up front, let’s say that alot is a “graphical” interface to notmuch, which you might know or remember as a mail indexer and search tool.

2015-04-14-6m47421-alot-01 2015-04-14-6m47421-alot-02 2015-04-14-6m47421-alot-03

And as you can see, alot has a lot πŸ˜› of the right stuff — good color, very flexible terminal space, on-screen help and an intuitive interface. Navigation is with enter keys and a few other mnemonics, and some keys have global behaviors, regardless of what you’re doing at any moment in time.

I would bet that, once your mail setup is complete, you’ll only need about three or four minutes to learn how to use alot, and after that, you’ll cruise through your mail folder at ludicrous speed.

A few things to remember though. … alot needs notmuch on board, which means you’re dealing mostly with the local mail concept, as opposed to relaying directly to an online mail source. If you’re looking for something that will pull down messages from GMail and let you pick through them, I don’t think this is it.

On the other hand, it does mean that you’re free to latch alot (and notmuch) on to your home-grown mail system — or as I showed above, latch notmuch onto something like offlineimap, which can yank messages off GMail and store them locally.

So technically speaking, there are options. The question becomes, how much do you want to step backwards through programs, just to take advantage of alot, when things like alpine can more or less handle the entire process in one fell swoop? Again, if you use a local mail system, alot might be preferable. For me … well. … 😐

All in all, I have to give alot a gold star for catching every point in my checklist for a good console application. I don’t think this is a game-changer for me though, since I’d have to rely on two or three other programs before alot became my mail reader, even if setup is fairly straightforward for all of them.

In AUR as alot and alot-git, but the git version wasn’t working at this exact moment in time. In Debian. And of course, as promised: ⭐ Enjoy! πŸ™‚

andatool: Searching forever and ever

I had one more logging tool related to genstats and logintop10 that I wanted to point out, and unfortunately I can’t do much more than this when I show it.


That’s a disappointment on two counts, first being my relative dunderheaded attempts at feeding andatool a proper regex string. I’m dunderheaded about regex on the whole, so I suppose it’s not to be expected.

The other disappointment is in the fact that andatool is continually skimming through my /var/log/pacman.log file, forever and ever, looking for matching strings. As the log gets updated, the counts update … or they would, if I could get it working and show an animated image.

So you’ll have to use your imagination. Or you could build it yourself, give it a professional-grade regex string and a proper log to look at, and see how it works for you. Never trust me on these things. πŸ˜•

I can give you a few pointers though. You have to designate a file for andatool to skim through, with the -i flag, and you have to give it the full path. That might sound obvious, but I wrestled with that for a little bit.

Also, it seems more intuitive to use the -s flag each time, since that tells andatool to start at the beginning of the file and work the whole way through. I can imagine where it might be useful to omit it, but all of my best attempts were more interesting when I included that flag.

And I should mention that you’re not limited to one expression, so you could search through a log for several different instances, and watch each one update.

I don’t recall too many live log filter tools, so andatool seems worthy of mention. Not in AUR or Debian that I could find; don’t let that keep you from trying it though.

mps: Not unlike its brother

I was sorely tempted to gloss over mps, because I mentioned mps-youtube way back in September. But I’ve spent a short time with it and I think it’s worthy of mention in its own right.


mps sticks very close to mps-youtube in terms of operation and playback; enter a search term at the startup and mps will show a series of results. Cue the number of the track and mps feeds it into mplayer (or mpv), and the standard keys and controls are available to you.

The home page for mps suggests it can also create playlists, search for single tracks or through album lists, download tracks as well as stream, and a few other nifty tricks.

The home page also says the program works with python 2.7 and 3.3, but does not require any python dependencies. I’m a little fuzzy on that, but as a general rule of life, I subscribe to the principle that less dependencies is better.

I’ll keep this short since much of what mps does is similar to mps-youtube, and rehashing the features of one isn’t necessarily an endorsement of the other. If you liked the way mps-youtube worked — and I did, quite a lot as a matter of fact — mps is going to be familiar and enjoyable. Try one, try the other. πŸ˜‰

cscope: The code navigator

Short post this time, since I have almost no frame of reference for cscope. I have all the coding ability of a day-old banana peel, so a tool that searches, arranges and navigates source code files is far and beyond me.


That’s cscope picking through the source code for curl, which was just an arbitrary choice. Nothing to be inferred in that.

It’s a very smooth tool though, and if you spend any time at all navigating large files or skimming through trees of code, I can see where cscope would be a huge asset.

From my very cursory inspection, you can set search strings or patterns through the prompts at the bottom of the screen. Matching lines will appear in the top half, and you can use the arrow keys to pick through them. Press enter, and cscope opens your $EDITOR for you to make changes.

Help is available at the ? key, and you can exit with CTRL+D. Just so you know. …

I know very little about coding, even less about cscope, and have only a brushing knowledge of some of the search tools aimed at developers — programs like ag or ack. I can see where cscope might be preferable though, since it offers an interface to your activity.

But of course, you are the best judge of that. πŸ˜‰

tagfs, xtagfs, dhtfs and more: Tag, you’re it

For some reason, the last file tagging utility I mentioned, tagsistant, touched off a flood of suggestions on tagging titles. Four or five came from just one contributor alone, and I got e-mails about two or three more from other counties.

I didn’t know file tagging tools were so prolific. I’d always just relied on directory trees as the simplest way to arrange things, but now it seems I am living in 1988. 😐

Anachronistic me aside, I’m terribly grateful for all the suggestions. But the sheer volume — and the time it would take to build, set up, learn, playtest and evaluate all of them — means I must go the short route, and list them here as potentially interesting to you, the reader.

I don’t like doing this because there are undoubtedly some very useful tools in here, and it levels the field between the truly genius and the truly jejune. It’s hard to spot a real winner in a crop this dense though, so if you can attest to any one of these, please give us a steer.

  • Dantalian: By the home page’s admission, a “multi-dimensionally hierarchical tag-based transparent lightweight file organization system.” This struck me as closest to tmsu, which I liked best of what I’ve used.
  • debtags: If I understand correctly, debtags is the Debian solution for tagging the tens of thousands of titles in their collection, and that’s quite a testament. tagcoll, if I read the wiki right, is the go-to tool for manipulating the tags. I don’t know (but perhaps you do) if debtags or its underlying structure are applicable beyond that project itself.
  • dhtfs: A tagging system that sports “dynamic directory hierarchies based on tags associated with files.” That suggests to me that the directory structure will evolve as the tags are applied, which is either attractive or horrifying, depending on you. Personally I’m curious in a morbid kind of way, because I like to manage the way things are arranged on my system. Perhaps I shall set up a dummy system and try it out, just for kicks.
  • django-tagging: Kevin sent this one by e-mail, but I don’t have any experience with django, and I think this might go way beyond what I could investigate.
  • flickerfs: This one might be oddball of the group: I believe this latches on to your flicker account and allows you to work the tags in use there. But I don’t use flicker, and so I might be way off base with this one. Thanks to Lars for suggesting it though.
  • pytagsfs: I see this in Debian with the description, “arranges media files in a virtual directory structure based on the file tags,” which might mean it works something like dhtfs for audio files. I might give this one a try later. The home page listed on the package page doesn’t seem to be related to the project, though.
  • stagfs: A “proof-of-concept non-hierarchical FUSE file system deriving structure from independent tag files.” The term “proof-of-concept” says to me that it wasn’t intended for actual use, but it might be a viable product, so don’t take my word for it. I am quite frequently wrong. 😦
  • tag-fs: I have my doubts about this one, only because the downloadable source file is all of 36.7Kb, and the trunk is suspiciously concise. Also, it doesn’t appear to have seen updates since 2008, which is not necessarily a bad sign, only a little worrisome.
  • tagfs: Not to be confused with the previous project, this has seen more recent updates and appears to be (have been?) a more complete effort. It also seems to have an approach like tmsu or tagsistant, and I can see where it might have inspired those two titles. Another of Eric Davis‘s suggestions from a month ago.
  • tracker: tracker confuses me a little bit: Apparently this is a plugin for Nautilus, but I also see that there are things like tracker-utils in Debian, so maybe there are text-based tools that can run it too. If you use GNOME :\ you may want to investigate further. If they can’t be split off from the graphical component, then. … 😦 Thanks to Jonas for the note.
  • xtagfs: I have a strong suspicion this is intended as a tool for Macs, but I won’t discount it out of my relative ignorance about Mac-related software. And sometimes I see where tools written for Macs are implantable in Linux systems. You probably know better than me. … 😐

Of course, like I implied earlier, I simply don’t have the time right now to work with every title here, and so there may be one or two in there that are not only incapable or inappropriate, but impossible. My apologies if you stumble across something so useless as to be laughable. I feel obligated to share the information I receive, since people are kind enough to pass it my way. Just remember, as always, your mileage may vary. Happy tagging. πŸ™‚

tagsistant: Tagging with a different approach

After my great delight at trying tmsu, I was willing to try out tagsistant on Eric Davis‘s suggestion. And between the two of them, I think Eric is right: tmsu might be a better fit for me too.


I can see similarities between tmsu and tagsistant; both use directory trees to arrange tags, and to show combinations between them. tagsistant seems very intuitive when it comes to finding mixed tags, with a simple plus sign showing combinations, and so forth.

tagistant “tags” files by “copying” them into a tag folder, which means adding an entire subfolder is a lot easier than tmsu was. And you can tag a directory itself, without necessarily applying the tag to files inside it. I can see where that might be preferable, and the home page suggests that will keep the database slim.

tagsistant is also file-manager friendly, and I suppose the same thing could be said about tmsu. Once I had a few files tagged and cross-tagged, I could work my way through the directory tree with Midnight Commander, and see how files were arranged between tags.

Probably the best part of tagsistant was the setup. The home page shows you in simple steps how to create a tag system, tag individual files and work the query process. It’s a very comfortable introduction.

My complaints against tagsistant are also simple and fairly straightforward: Perhaps biggest, there’s no way I could see to query the tag system without working through the folder tree.

With tmsu I could just ask it outright what tags were applied to a file, but I don’t see an analogue for that in tagsistant. Please point it out to me, if I’m just being dense.

Second, I see no expedient way to apply multiple tags at a time. The copy-file-to-tag motif is an interesting approach, but it doesn’t lend itself to adding three or four tags at once. I prefer tmsu’s approach, of just listing tags in quick succession.

That might go back to my first, and this last point, just that the tree structure for tagsistant is a useful format, but can be very cumbersome without a file manager. Tab completion helps, but each query up or down the tree is going to require some backspacing, correction and possibly even retyping. My advice? Pick a quick file manager. :\

(Of course, maybe if you could combine this with something like commacd, you might have a very powerful combination. … 😐 )

tagsistant is by no means an unusable tool, and depending on your files and tags, you may prefer this over other options. Definitely look through the advanced documentation, because it will help you with a lot of tagsistant’s finer points.

As for myself, I’ll stick with tmsu, unless one of Eric’s other recommendations wins me over. … πŸ˜‰

cfind: A search tool built on a search tool

I had to read the home page for cfind more than once to figure out what it does, but I don’t think reading it any more will help me understand why it would be useful.

cfind “provides functionality similar to that of Google Desktop from the command line” — and that much I understand. But the little intricacies are escaping me.

cfind needs locate, which is part of mlocate in Arch and not installed by default. Before you can use locate, you have to run updatedb. After that, locate can scramble through the database of your files and pull out just about anything you want, in fractions of a second. That we saw long ago.

Before you can use cfind, you have to run cindex, it’s partner application. Once all those steps are complete, you can query cfind for search strings. So once more: updatedb, then locate if you want, then cindex, and finally cfind.

And here’s the kicker: cfind and locate will generate almost identical output, with two exceptions that I can see. cfind apparently only searches through text and TeX files, and cfind orders its results by “relevance.”

Here’s what it looks like when it’s finished, sort of.


There I sent the results of locate, on the left, and cfind, on the right, through paste with column -t | most for readability’s sake. πŸ˜‰

I guess my confusion lies in the need for a tool to skim a database made from another database, when there’s already a tool that skims the original database. O_o How is cfind better than using straight locate, and filtering the results for TeX or text files?

These are the questions that keep me awake at night. 😐

I appreciate that cfind might fill a niche, but I only rarely work with TeX files and don’t have enough text files to justify a search tool built on a search tool. And without any guidance on its algorithm for “relevance,” I don’t think I’ll be keeping this around.

For the record, this is the second tool I’ve come across in two years that lays claim to the “Google Desktop for the CLI” title. The other, you might remember, was doodle. Neither one seems to have usurped the standby, Unix-esque tools — find or locate — that are already available. 😦