Tag Archives: search

ngp: Find it and edit it, in one deft motion

These days I seem to be finding less and less tools that really grab me, and more and more that seem to fall short of the mark somehow. ngp is one of the former, and this one I think I shall keep around.

ngp is like a recursive, colorized, interactive grep. If you take the output of ack, make it navigable with a selection bar, then add the ability to jump straight into a selected file with your $EDITOR, you’ll have an idea of what ngp does.

So for example, this

 ngp -r ion

Takes me straight to this:


And from there, if I highlight a line and press enter, I jump into $EDITOR and can adjust as necessary. Leave the editor and ngp reclaims the terminal, showing the same results but with red text, so I know I already traveled there. Very smooth. ๐Ÿ˜Ž

ngp strikes me as a tool someone would invent where they see themselves repeating the same task over and over, and relying on two or three terminal windows to track their progress. And if you work in text files a lot, or through trees of code, I imagine ngp would save you some time finding certain problems, and fixing them.

ngp can be a little finicky, so watch your flags carefully. And I might have compared it to grep but it’s not feature-compatible, so don’t start throwing wild strings of flags at it and expecting it to munch them down the same way grep does.

But for a find-and-replace or find-and-edit or search-and-destroy at the console tool, ngp has everything tied up in one, nice, neat package. A well-earned, albeit completely valueless, K.Mandla gold star: โญ Enjoy! ๐Ÿ˜‰

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. … ๐Ÿ˜ฏ

tmenu: Just one step away

The next time you hear someone whine about having to use the command line, you can provide them with a long list of utilities that deftly convert lists and applications into menu format. Putting aside pdmenu — the dedicated application menu tool for the console — you still have things like slmenu, fzf, sentaku, percol and now Dario Hamidi’s tmenu

2014-09-07-6m47421-tmenu-01 2014-09-07-6m47421-tmenu-02 2014-09-07-6m47421-tmenu-03

tmenu works a lot like sentaku or percol, accepting piped-in lists and returning to the screen. Unlike fzf, tmenu does not assume you want the current list of files, so you have to provide something; just entering tmenu gives you an empty list and a rather pointless tmenu experience.

With a proper list, you have the option to filter by character string, or navigate with CTRL+N, CTRL+P and so forth. Press return, and your selection is returned to STDOUT.

So this too can function in the same way as the slmenu gimmick, without the color that percol offers, without the vertical arrangment that fzf has, and perhaps a little more space-conscious than sentaku.

tmenu takes three flags — one for the number of items in the displayed list, one to change the prompt and one to take out the status line. That’s it. Very simple.

About the only thing I don’t like about tmenu is the lack of arrow key controls for list navigation. I know that’s fairly minor, but my instinct is to jump for the arrow keys when I’m presented with a list. CTRL+N and CTRL+P make sense when I think about them, but there’s always that split second when I don’t think, and just start tapping fruitlessly at the arrow keys. Grr.

All that being said, I’m wondering if it’s not time to just hotwire tmenu — or one of its brethren — into the /usr/bin folder and run it perpetually, like a Grand Unified Menu. And so this

$(ls /usr/bin | tmenu -l $(tput lines) )

Would give you this:


Not as scary as I thought. I guess we’re all just one step away from a completely menu-driven terminal experience. ๐Ÿ˜‰

ack: A grep for programmers

I am vastly undequalified to speak about ack, since the home page makes it abundantly clear that it’s a perl-based grep-like tool intended for programmers.

I am not a programmer, unless an emergency arises, and then there would be a better chance of success by employing a blind, one-armed, drunk monkey to smack at a keyboard for a few hours. I am quite confident of that.

But ack is on my list and I’d feel slightly guilty if I didn’t include it, since it was relayed to me by email from a reader (who asked to remain nameless). So here is my best attempt at ack, and the wizardry it reportedly can perform.


Let’s see. Color? Check. Easily readable output? Check. Searches entire tree? Check. Returns results with file and line number annotated? Check.

Well then, that’s my whole list.

As I understand it (because again, this is not a tool intended for the peons, like me) ack is supposedly faster or more complete than the traditional grep, and carries defaults specific to searching trees of source code files.

Not that grep can’t do those things. …


Only that ack supposedly does them better. Or at least that’s the impression I get from the Web site.

Like I said, I’m not a programmer so I don’t feel qualified to pick between the two. I have no preference for either, and I’m likely to stick with grep just because grep appears on my Arch system (and some others) by default.

I can be lazy that way. ๐Ÿ™„

lbdb: Looks can be deceiving

I mentioned bbdb last week along with charrington, as an address book tool for within emacs. Out of fairness, I feel I should mention lbdb as well, although it doesn’t look like much from where I sit.


lbdb, for what I can tell, is mostly a search tool for address books, whether created by your system or by other software. As a scientific guess, I would reckon from the configuration file that lbdb is prepared to scrape through about a dozen different address files and mail systems, as well as your /etc/passwd and other local system files, to find the person you’re looking for.

Above you can see what little there was for it it search in my .addressbook file, created by re-alpine and compatible with its “m_pine” search method. You’ll need to copy /etc/lbdbrc to .lbdbrc, add the method you need to the METHODS line, and make sure that the remainder of the variables in that file match your setup. For example, since my .addressbook file is actually at ~/.addressbook, I didn’t need to adjust line 84.

After that, lbdbq "name" would search through the file and return anything matching “name.” Easy as that.

But also as simple as that. I experimented with lbdb and its incorporated tools for about a half an hour, but what you see in that screenshot above is about the best I got out of it.

I know it’s not very impressive, but my .addressbook file is not very impressive either. If I had a few more names and addresses, then I would probably find lbdb a little more useful.

And of course, if you’re working on a system with a multitude of address and e-mail tools available, for several users or perhaps multiple systems, lbdb might give you more pause than it did for me.

Like a lot of things I come across, I have a feeling lbdb only looks unassuming because my own system is so terrifically meager. And looks can be deceiving. ๐Ÿ˜

pirate-get: A tool is just a tool

I have to remind myself that today’s first treasure is just a tool, and a tool is just a tool. What you do with these things is none of my business.

pirate-get, as you might infer, performs a search of the world’s most infamous bittorrent tracker, and returns the results in the console.


I could leave it at that, and allow you to glean from that what you will, but there are a couple of things that pirate-get does that are worth pointing out. And not for any reasons except that it does those things well.

First, as you can see above, pirate-get by default returns results in descending number of seeds. I really, really like that, because searching for — ahem — Linux ISOs is not just a matter of what best matches my search terms, but what matches and is available. Perhaps you can sympathize.

Second, pirate-get will automatically cue up transmission-remote and send your selection through. This, as you can also imagine, speeds up the search-to-download process on the whole … if you use Transmission, of course. ๐Ÿ˜‰

For those who don’t, pirate-get can accept a --custom flag, and pass the link to another program. I tested it with pirate-get Ubuntu --custom "deluge %s" and it gracefully handed off the magnet link to a running session of Deluge, no questions asked.

Which brings up an important point: By default, pirate-get returns the text of the magnet link to your $BROWSER, and I don’t see an option to download the actual torrent unless you somehow pipe that link through another site or utility that will convert it. If I don’t include the custom command with pirate-get, my selection is dumped into elinks, which only shows an error message.

So keep that in mind if you prefer to work with the actual torrent (some people do; I know, it’s old-fashioned) you might need to do a little jerry-rigging to get it going to your satisfaction.

(I will add one other small complaint, and it’s a fairly obvious one: As far as I can tell, pirate-get only works with … well, you know. One tracker. If you prefer others, you’ll have to dig into the code or search around for alternatives to pirate-get.)

I like pirate-get a lot, mostly for the things I’ve mentioned above, but also because it can do things like return “all” the results at once, or spit out the torrents added in the last 48 hours. It’ll also show descriptions and file lists, which can be helpful if you’re skimming through a list of distros and aren’t sure what’s what.

One last note: There’s a --color flag available, and what you see in the screenshot — basically alternated bolding — is the result. Personally that doesn’t really qualify as “color” in my mind, but I’m willing to overlook it. If you want to get that effect, you’ll need to install python2-colorama, for the Arch version at least.

That’s all I’ll say about pirate-get. I’m sure you will use this tool in only the most honest and forthright adventures, and eschew any temptation to use your newfound powers for evil. ๐Ÿ™„

fzf: More menu-like options, with fuzzy finding

I said a long time ago that find is one of the greatest creations for computers, probably since the invention of electricity.

Junegunn Choi’s fzf might make you think hard about it though.


That’s a slooow animated gif, isn’t it? I’m experimenting with stop-motion animation. ๐Ÿ˜†

In much the same vein as sentaku and percol, fzf accepts a list — by default, the list of files in the current directory tree — and allows selection by way of fuzzy finding. As you can see there, not only does fzf pluck out entries that contain “an” exactly, but also retains options for longer, less-strict matches.

Making a selection returns the value to STDOUT, making fzf another candidate for the oft-mentioned slmenu gimmick. Again, though, like percol, you might have to arrange that list of programs as a text file.

Then again, maybe not.

ls /usr/bin | fzf

Oooh, that’s tempting fate right there. ๐Ÿ˜ฎ

fzf is a lot less visual than percol or sentaku, but approaches the concept — picking out a selection from a large list — from a pattern matching perspective. It would take a little more command-line prowess to make percol act in the same way.

fzf is fast, clean, colorful, useful, intuitive, easy to use and doesn’t require a complex set of commands to employ. It can return multiple selections, and it plays well with other Unixy tools. So as Junegunn suggests, something like

vim $(fzf)

is viable. (I should probably mention that I tried to shunt the results of find into fzf, but there were some snags.) It might also play nicely with something that cues music files. Think about that one for a little bit.

I’ll leave you alone to meddle with fzf for a bit. Perhaps even more than slmenu or sentaku or percol, fzf has the potential to change the way you work at the command line. And for that … I think fzf is eligible for a rare K.Mandla gold star: โญ Enjoy! ๐Ÿ˜‰

cliwiki: Needing attention

I try to be as honest as possible when I look over software. If it seems like I’m too-often enthusiastic about programs, it’s probably because the ones that were less than gratifying were cast aside out of frustration.

I’ll list cliwiki though, since I sense it has a little potential, and a tool that pulls pages from Wikipedia is worth pursuing.


I don’t recall where I got the link to cliwiki, but my assessment is that it needs more attention. Here’s why:

  • The few arguments cliwiki claims to support produce nothing. The home page suggests potd, featured and onthisday, but none of those generates any different results.
  • cliwiki requires you answer a prompt to trigger the search. You can’t tack on the topic as a command line argument.
  • cliwiki incorporates no pager, and because of the prompt, it’s exceedingly difficult to page or redirect the output of very long pages.
  • Because of those shortcomings, I’ve tried to funnel cliwiki into text files with the standard > mark or a pipe symbol, but the prompt confounds things. I get half-formed pages or worse, lockups. For what it’s worth I’ve also tried to echo my search topic into a text file and use < and xargs in one fashion or another, with no real success.

All of this means to me that cliwiki is only half-formed, and partially useful on pages that don’t overflow your terminal window. I daresay on very shallow screens it will be nigh-on useless.

cliwiki does do some things right; I like that it lists links at the end of the page, and adds links to images in the text. But cliwiki still needs a bit more work before it’s functional, either to the degree it promises or to a point of usability.

glyrc: A music search, for everything but music

For the meticulous music collector, I have a suggestion today that you might find intriguing: glryc.

2014-07-25-lv-c5551-glyrc-01 2014-07-25-lv-c5551-glyrc-02

Technically speaking, glyrc is a command-line tool for the glyr library, which is specific to retrieving lyrics, cover photos, guitar tabs … you name it, from a list of online hosts.

Seems to me, the only thing it doesn’t retrieve is the music itself. We can’t have that, now can we? :\

Supposedly glyr is use in a few music players, but it works just as well with its command line tool. Tell glyrc what you want to retrieve, add a tag for the artist and/or album, and wait patiently while it does its work.

Perhaps even more useful would be to wire glyrc into a script that reads through folders and subfolders, and pulls down all the metadata for each album in your collection. If you’re one of those people who manages their music, that is … and doesn’t rely on the application to do that. ๐Ÿ™„

There’s not a lot more I can show you about glyrc, even though there’s a lot more potential here. My favorite point thus far is the option to download backdrops (think: wallpaper) by artist or album. Rabid fans can pull down an image a day and rotate through their collection, if they have a smidgin of coding expertise.

I’ll leave you to explore glyr and glyrc further; its usefulness and appeal will be directly proportional to your taste in music, and your need to flesh out the metadata of your collection. ๐Ÿ˜‰

howdoi: Because the Internet knows more than you

I picked howdoi as a complement to betty today, because in some ways, they both do similar things.


Whereas betty would reply with set answers (provided she knew the questions ๐Ÿ™„ ), howdoi acts as a conduit between you and that vast cesspool in the sky, The Internet. Give howdoi a few key terms, and it will give back what it hopes is an answer to your conundrum.

howdoi is aimed mostly at coders, as I understand it, but as you can see, it will handle system admin or just bash issues too. I even asked it a question or two about vim, and I think it gave the right answer. It’s hard to tell with vim. ๐Ÿ˜ I didn’t ask it for the weather in London. ๐Ÿ™„

If you tinker with howdoi for a few minutes, you’ll see what it’s doing: searching through StackOverflow, and replying with a best-case answer formatted for your screen. If you ask nicely (in other words, use the -a and/or the -c flags) it will prettify the result, and give a link to where it was found.

I can’t fault howdoi very much, since for the most part, it seems to give the right answers. On the other hand, as you can see above, it doesn’t really know what you’re asking — I don’t think that is the right command to add a user with bash. ๐Ÿ˜‰ So remember: It’s just handing down the wisdom of the unwashed masses, and hoping you will be pacified.

In that way, howdoi is really just a well-designed search utility for the console, like surfraw is and a few other tools do. I’d have to check to see how it’s designed, and whether it actually looks through more than just StackOverflow; I’ve only seen links to that site.

So in all, I can’t complain about howdoi the same way I do about betty. If you’re a coder and you sometimes find yourself fishing for snippets, howdoi is a short and quick tool that gives out just the right amount of info. On the other hand, be aware that while the Internet will always know more than you, what it knows isn’t necessarily something you want to learn.

P.S., Yes, there is an elvi for StackOverflow in surfraw. In case you were headed there next to check. …