Tag Archives: filter

colormake: Does what you’d expect

On the one hand, I can admire colormake for its simplicity.


On the other, that’s about all it does. I will grant that colormake does convert make’s output to something more readable, but I also have to admit that the color doesn’t do much to help me understand what make is saying. 😦

Calling colormake is not particularly different from using make itself; you can apparently use it in almost every case where make is used. Even asking for help with -h or --help sends that request straight through to make, and you’ll get make’s quick help listing.

Which means if you want guidance you have to go straight to the man pages. And for what I’ve seen, there’s only one flag you can give colormake, which specifies an exact makefile, as opposed to just Makefile, I believe.

colormake is in Debian and AUR, but I see some differences between the two that suggest the Debian rendition hasn’t been updated. The only colors I saw in the version yanked from Debian were white and cyan, but the AUR version pulls its source from Github and was much more colorful.

I feel obligated to mention that there is an identical (knockoff?) project in Daniel C. Jones’s namesake program, the main difference being the use of python, I believe. So hey — two-for-one today! πŸ˜€ πŸ™„

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.

talkfilters: All that computing power, and this is what you come up with?

After falling flat with yesterday’s attempt at an amusement for the console lifestyle, I thought perhaps talkfilters might be able to give me a quick giggle.


Well, I smirked at one or two.

talkfilters is exactly what you think it is — a series of filters that exchange certain words or letter sequences for analogues spelled or arranged to poke fun at certain dialects or speech patterns. Or individuals.

In some cases, it’s not so much a filter as an insertion tool though, with sporadic phrases interjected at points. Sometimes it’s funny, sometimes it’s just an obfuscation. And sometimes there’s probably a joke in there, but I don’t know what it is. :\

Like any attempt at comedy, talkfilters is likely to insult you if you think you’re the target of its humor, and I see one or two in there that might even be jabs at me. Not personally of course, but probably at my own demographic.

I don’t really care though. If your sensibilities are so fragile as to take offense at a juvenile filter that translates into an “accent,” then you haven’t been exposed to the real problems that can happen in life.

Regardless, I can see where one or two of these might have an application beyond the comic, and the buccaneer filter is likely to be of use sometime in September. Aside from that, I don’t know if there’s much other than comic relief they can offer. If they even do that. … 😐

P.S.: In Arch as talkfilters, in Debian as just filters.

urlscan and urlview: With the assist

Not having a lot of experience with the convenience and immediacy of local mail service, I find that things like urlscan and urlview are sometimes lost on me.

I’ve done my best though, to try and see the fearful symmetry of urlview, which skims through text files and plucks out viable URLs, then displays them as links. How would that be useful? When sent an e-mail filled with links, of course.


From there, it’s a simple hop-skip-and-jump to your fav-o-rite browser, and you can wallow at your leisure in the murky swill of the Internet. :\

And it’s got most of the requisite points — some color, a full-screen interface, abort keys on screen. Granted, it’s simple, but not so simple as to be unnoticed.

urlscan is a re-imagining of the task, and is written in python. You can probably see the resemblance.


And you can see where there’s a slight variation on the original theme, with a top-and-bottom arrangement over urlview’s list-and-status bar style. You pick your preference.

(I did notice, just as a side note, that urlscan seemed to glance over URLs that were prefixed with http:// but that may have been a quirk in my test list.)

Other notes: urlview has a complete configuration file in /etc/urlview/. urlscan can dump its ouput to STDOUT. Both expect you to configure $BROWSER beforehand, although I believe urlview can rely on its own configuration files too. Both are in Debian and Arch/AUR.

I feel obligated to mention that both urlview and urlscan are quite happy working their magic on plain text files, and don’t rely on any mail system whatsoever to work (which should be obvious from my screenshots). So if you have a project that needs to skim for web addresses, either will probably suffice.

On the other hand, I can’t really think of many ways to use either program beyond what they’re designed for — filtering through e-mails and displaying links. Perhaps in time I will find something to use them with. … πŸ˜‰

wiki-stream: Less than six degrees of separation

I didn’t intend for there to be two Wikipedia-ish tools on the same day, but one good wiki-related utility deserves another. Or in this case, deserves a gimmick.

Josh Hartigan‘s wiki-stream (executable as wikistream) tells you what you probably already know about Wikipedia: that the longer you spend daydreaming on the site, the more likely you are to find yourself traveling to oddball locations.


You might not think it possible to travel from “Linux” to “physiology” in such a brief adventure, but apparently there are some tangential relationships that will lead you there.

I don’t think Josh would mind if I said out loud that wiki-stream has no real function other than to show the links that link between links, and how they spread out over the web of knowledge. Best I can tell, it takes no flags, doesn’t have much in the way of error trapping, and can blunder into logical circles at times.

But it’s kind of fun to watch.

wiki-stream is in neither Arch nor AUR nor Debian, most likely because it’s only about a month old. You can install it with npm, which might be slightly bewildering since the Arch version placed a symlink to the executable at ~/node_modules/.bin. I’m sure you can correct that if you know much about nodejs.

Now the trick is to somehow jam wiki-stream into wikicurses, and create the ultimate text-based toy for time-wasting. … :\

wikicurses: Information, in brief

If you remember back to wikipedia2text from a couple of months ago, you might have seen where ids1024 left a note about wikicurses, which intends to do something similar.


Ordinarily I use most as a $PAGER and it might look like most is working there, but it’s not. That’s the “bundled” pager, with the title of the wikipedia page at the top, and the body text formatted down the space of the terminal.

wikicurses has a few features that I like in particular. Color, of course, and the screen layout are good. I like that the title of the page is placed at the topmost point, and in a fixed position. Score points for all that.

Further, wikicurses can access (to the best of my knowledge) just about any MediaWiki site, and has hotkeys to show a table of contents, or to bookmark pages. Most navigation is vi-style, but you can use arrow keys and page up/down rather than the HJKL-etc. keys.

Pressing “o” gives you a popup search box, and pressing tab while in that search box will complete a term — which is a very nice touch. There are a few other commands, accessible mostly through :+term formats, much like you’d see in vi. Press “q” to exit.

From the command line you can feed wikicurses a search term or a link. You can also jump straight to a particular feed — like Picture of the Day or whatever the site offers. If you hit a disambiguation page, you have the option to select a target and move to that page, sort of like you see here.


That’s a very nice way to solve the issue.

There are a couple of things that wikicurses might seem to lack. First, short of re-searching a term, there’s no real way to navigate forward or back through pages. Perhaps that is by design, since adding that might make wikicurses more of an Internet browser than just a data-access tool.

It does make things a little clumsy, particularly if you’ve “navigated” to the wrong page and just want to work back to correct your mistake.

In the same way, pulling page from Wikipedia and displaying it in wikicurses removes any links that were otherwise available. So if you’re tracking family histories or tracing the relationships between evil corporate entities, you’ll have to search, read, then search again, then read again, then search again, then. …

But again, if you’re after a tool to navigate the site, you should probably look into something different. As best I can tell, wikicurses is intended as a one-shot page reader, and not a full-fledged browser, so limiting its scope might be the best idea.

There are a couple of other minor points I would suggest. wikicurses might offer the option to use your $PAGER, rather than its built-in format. I say that mostly because there are minor fillips that a pager might offer — like, for example, page counts or text searching — that wikicurses doesn’t approach.

But wikicurses is a definite step up from wikipedia2text. And since wikicurses seems to know its focus and wisely doesn’t step too far beyond it, it’s worth keeping around for one-shot searches or for specialized wikis that don’t warrant full-scale browser searches. Or for times like nowadays, when half of Wikipedia’s display is commandeered by a plea for contributions. … πŸ™„ 😑

pup: Playing fetch with HTML

Every month I export the posts from this site, grind away at the XML file, pluck out titles and links, and rearrange them to form an index page. Don’t say thank you; I do it for me as much as anyone else. I can’t remember everything I’ve covered in the past two years, and that index has saved me more than once. :\

Point being, it takes a small measure of grep, plus some rather tedious vim footwork to get everything arranged in the proper order and working.

You know what would be nice? If some tool could skim through that XML file, extract just the link and title fields, and prettify them to make my task a bit easier.

pup can do that.


Oh, that is so wonderful. … πŸ™„

In that very rudimentary example, pup took the file, the field I wanted, and sifted through for all the matching tags before dumping it into the index file.

pup will also colorize and format HTML for the sake of easy viewing, and the effect is again, oh-so wonderful.


That might remind you of tidyhtml, the savior of sloppy HTML coders everywhere, and you could conceivably use it that way. pup can do a lot more than that, though.

You can parse for multiple tags with pup, filter out specific IDs nestled in <span> tags, print from selected nodes and pluck out selectors. And a lot more that I don’t quite understand fully. 😳

It is possible that you could do some of what pup does with a crafty combination of things like sed or grep. Then again, pup seems confident in its HTML expertise, and the way it is designed is easy to figure out.

And for those of you who won’t deal with software more than a few months old, I can see that at the time of this writing, pup had been updated within the week. So it’s quite fresh. Try pup without fear of poisoning your system with year-old programs. πŸ˜‰