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

iselect: A program’s got to know its limitations

I just mentioned fselect the other day, but it’s only by coincidence (and the fickle hand of Fate, as conveyed through ls vimwiki/ | shuf -n1) that I have iselect today.

iselect has all the hallmarks of fselect and other line selection tools, but seems to be conscious of its role as an intermediary.

That’s a kind of oddball thing to say, so let me explain.

Invariably, the curses-based selection tools that we’ve seen over the past couple of years all share the same idea: Accept a list or line of options, present them as a menu, and then return the result when cued. All the way back through fselect and sentaku and slmenu, that’s been the idea.

iselect does that, but can torque that idea just slightly, to allow for some other information to pass through.

For example, add the -K flag, and not only will you get the selection sent through STDOUT, but you’ll get the keypress your human used to designate it.

You can also confound your human by making everything in the list un-selectable. Imagine the hilarity. 😐

iselect will also allow multiple selections — done with the spacebar — or force single-selections. It can accept zero- or one-item lists, and allow your human to wander through that seemingly empty exercise, and come up with a selection. Or it can do the opposite, and exit as soon as it detects an empty list, and not waste anyone’s time.

Look at the help flags for iselect if you want those or other options; the version installed through AUR does not include a man page, but if you’ve used other selection tools in the past, you’ll have no trouble navigating it. iselect is in Debian-based distros as well.

I don’t spend enough time with selection tools like this to know if there’s one god-given tool that everyone relies on in their projects and adventures. For what I’ve seen of iselect though, if I was using a selection interface in my program, I think I’d go with this one. It seems to know why it’s there, and what its purpose is.