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

wikipedia2text: Looking well-preserved, thanks to Debian

Conversion scripts are always good tools to know about, even if I don’t need them frequently enough to keep them installed. wikipedia2text is one that, in spite of its age, still seems sharp.

Technically, the script’s name was just “wiki,” and technically the source link listed on the home page is dead. Late in 2005 though, it made its way into Debian, and is still in a source tarball there. So it seems that it is possible to achieve immortality — all you need to do is somehow find your way into Debian. 😉

The script works fine outside of Debian; just decompress it and go. You’ll need to install perl-uri if you’re using Arch. But if you’re in something Debian-ish, it should pull in liburi-perl as a dependency when you install it.

One thing that’s not mentioned outright in the blog post but does appear in the help flag: wikipedia2text will need one of about a half-dozen text-based browsers, to do the actual fetching of the page. I used lynx because … well, just because. Which leads me to this second screenshot.

At this point I’m wondering if wikipedia2text is an improvement over what a text-based browser can show. After all, lynx is showing multiple colors, uses the full terminal width, and I have the option of following links.

What’s more, wikipedia2text — strangely — offers a flag to display its results in a browser, and in my case it was possible to send the output back into lynx. So if you’re keeping track, I ran a script that called a browser to retrieve a page, then rerouted that page back into the browser for my perusal. 😕

In the absence of any other instruction, wikipedia2text will default to your $PAGER, which I like because mine is set to most, and I prefer that over almost anything else. Perhaps oddly though, if I ask specifically for pager output, wikipedia2text will arbitrarily commandeer less with no option to change that. Without any instruction for a pager, the output is $PAGER. But with the instruction it jumps to less? That’s also a little confusing. …

Furthermore, I couldn’t get the options for color output to work. And I don’t see a flag or an option to expand the text width beyond what you see in the screenshot, which I believe to be around 80 columns. That alone is almost a dealbreaker for me.

I suppose if I were just looking for a pure text extraction of a page, wikipedia2text has a niche. And it’s definitely worth mentioning that wikipedia2text has a text filtering option with color, which makes for a grep-like effect.

So all in all, wikipedia2text may have a slim focus that you find useful. I might pass it by as an artifact from almost 10 years ago — mostly on the grounds that it has some odd default behavior, and I fail to see a benefit of using this over lynx (or another text-based browser) by itself. 😐

the_silver_searcher: Intergalactic searcher smackdown

Uh-oh. I can already sense some friction between the_silver_searcher and ack, which you might remember as a sort of replacement for grep.

  

Left-to-right, ack, the_silver_searcher and grep. Please pay attention to the results of time.

Because it seems to me that both the_silver_searcher (which I will henceforth abbreviate by its executable ag, because that name is a little cumbersome to type) and ack pound their chests on their home pages, and suggest they are faster than grep. And ag definitely holds itself out as faster than ack. And I could swear ack claimed a speed difference over grep.

And yet in subsequent tests, I get results a lot like this …

	grep	ack	ag
time … “Time” list.txt	real 0m0.025s user 0m0.010s sys 0m0.003s	real 0m0.387s user 0m0.280s sys 0m0.010s	real 0m0.051s user 0m0.017s sys 0m0.007s

And grep is regularly faster than ack or ag. Q.E.D.

For the record, list.txt is a 75K list of television and movie titles that I scraped off the Internet just for this searching smackdown. No funky characters or encoding issues that I could see, and nothing but simple ASCII characters.

Maybe it’s my imagination and none of these programs attempted to be faster than another. And it’s important to remember that my tests are particularly gummy. I have an unnatural knack for screwing up some of the simplest setups, and an unscientific, unprofessional, unstatistical freestyle search-to-the-death would be no exception.

All that aside, ag strikes me as every bit as useful or friendly as ack, and seems to follow a lot of the same flag and output conventions. In fact, some of them appear identical. 😕

I suppose that means your choice of search tools will depend mostly on … your choice. In the mean time I’m going to turn up the heat on all three of these and check their results when I turn them loose on time {grep,ack,ag} main /lib/ … 😯 That will separate the men from the boys. 👿

P.S.: Thanks to riptor for the tip. 😉

lolcat: From the ears to the eyes

That last note about jdkdrum was missing a visual element, so I hope this one — lolcat — makes up for it.

From what I’ve seen, that’s about all that lolcat does — paints your emulator output in rainbows. Not that it’s less than expected, only that it might disappoint the terrifically serious types in the audience.

But that does mean it’s really just a cat tool … with the obvious addition of lol. 😉

There are a few options available to lolcat, and they either enhance or control the rainbow output that you see up there. There’s also an --animate flag that will cause each line to pulse through a rainbow before moving to the next … sort of like the old Atari computers used as video output. If you remember those days. 😕

I should mention that lolcat’s output is quite different from toilet‘s “fabulous” mode; if you look closely at the respective screenshots, you can see that each character in toilet’s output has a single color.

But lolcat is painting its output across individual characters, which is rather interesting. 🙂 lolcat will work in a virtual console, but you don’t get the same smooth rainbow effect. In fact, lolcat in a vc performs a lot more like toilet does.

lolcat is in AUR and is listed as on-deck for Debian Jessie, but both versions seem to come with a wicked mesh of ruby dependencies. If you’re expecting to just throw this on your old 300Mhz Pentium II laptop and start lolcatting news updates from across the web, there will be some patience required.

Ah, but the final product will be worth it, don’t you think?