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.

fselect: Pulled from the brink

I missed a day yesterday because of holiday travel issues, but I’m prepared to make amends with fselect.

I mentioned Peter Penchev’s original fselect in the past, but only in the context that it failed to build for me, and therefore fell into a category of software casualties. I suppose we have Theodore to thank for making it functional again. 😉

In that sense I can only look over what Theodore built, so it may be that the style and execution are part of the original, and not necessarily what Theodore worked to fix. 😉

As you can see, fselect allows you to select a file out of a list, and will return that to STDOUT as the results of its interaction. For what I could see, fselect only accepted file names in the same fashion as you might get from ls; in other words, I couldn’t cat a list of words to fselect and pick from them, like you might see in slmenu, sentaku, fzf or other file/text selectors.

fselect has some internal controls that you will want to know before you use it. Pressing Enter or Esc exits the program, but if you haven’t selected a file (or more) with the spacebar, you’ll get nothing from STDOUT.

If you’re just after one particular file, the dot key is a one-button combination of space-and-Enter, and sends your selection onward. That’s how something like vim $(fselect textfiles/*) is possible, as a quick-and-clean file selector.

fselect itself takes a few flags, perhaps most interesting being the -y command, which steps through the list of files one by one, and asks if you wish to select it. If you’re in a severely restricted environment or need to think hard on each choice, this may be a useful option to you.

I should note that it’s also possible to select directories with fselect, but I don’t believe there’s a provision for moving through directories. Please correct me if I’m wrong on that.

Just about the only suggestions I would offer would be color (which Theodore mentioned as a future development) and perhaps the option to use narrower file listings, rather than a full width listing in the manner of ls -lha. In an 80×24 terminal, depending on the width of the preliminary data, it was possible to cut off the file names from the right side of the display, making it difficult to see what you’re picking.

fselect is not in Debian or Arch that I could find, meaning if you want to tinker with either the original or resurrected form, you’ll probably have to build it from source. Be the first kid on your block to try it out. Tell people how you used fselect before it was popular. You’re so hip. 😉

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

  

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

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

percol: More menu-like options, plus searching and color

I’m a little behind the power curve in recent days. I dislike going on vacation for that one reason alone: Inevitably things get stacked up and are worse on the day after than in the time before. 😐

I’ve got percol to show today, and I think you’ll enjoy this one.

   

If you remember sentaku, percol might look a little familiar. percol adds the element of color, and some fuzzy searching as a bonus.

sentaku split menu items differently from percol, and if you want to inject this into the year-old slmenu gimmick, it might require the same menu-list approach as slmenu. The one-liner I suggested for sentaku doesn’t quite work the same way with percol. If that’s what you’re after, I recommend

eval $(cat menu.txt | percol)

instead, with the list of titles in menu.txt. You should get the same effect.

percol has a clean interface, obvious key commands and returns exactly what you select. There are a healthy number of options, so you can make it behave like you want. And the author suggests it can handle huge lists without too much sweat.

I can’t find any downsides to percol; sentaku took the slmenu trick out of the status line, and percol allows for even smoother menu selection. If there’s a fault to be seen in any of this, I can’t spot it. 😉

sentaku: More menu-like options for the cli

I thought I was being clever a year ago because I strung together slmenu and a few other random gimmicks, and came up with something like dmenu for text-only environments.

sentaku has that beat by a mile.

 

pipe text into sentaku, and it makes a full-screen pick-and-choose application from it. It’s complete with highlighted selection, vi-like or arrow-key navigation, help cues on-screen and best of all, a speedy response time.

The selected text is passed out of sentaku as-is, which makes it ideal for spawning applications or sending selections through to scripts. In other words:

eval $( echo "mc htop alsamixer elinks" | sentaku )

Does more or less the same thing as what I was doing with slmenu. Of course, mine had one-key popup menu access, and snazzy animated gifs. 🙄 But the same could be done with sentaku, with a little effort.

In case you’re thinking this must take a masterful command of assembly language to accomplish, it turns out that sentaku is just a bash script (or zsh, if you prefer).

And of course sentaku can be used for other things too. It’s not tied to menu selection, although that was what came to mind first.

I really like sentaku and I’d like to see it appear in AUR, if not in Debian as well. Perhaps I shall look into that … 😐

pdmenu: The bane of geek showoffs

Most of the console fanatics I know would sooner chop off all ten of their digits one-by-one with a rusty grapefruit spoon than surrender their blinky blinky cursor to something like pdmenu.

But pdmenu is really quite nifty, and if I may be so bold, no less supergeekcool than the slmenu gimmick I foisted upon the world last year.

Multicolor, full-screen, customizable, hooks itself neatly into Debian’s menu tool, has sane controls and defaults … what’s not to like?

Oh, that’s not dialectics, I actually know the answer. The bleary-eyed console addicts are addicted to showing off their 80 words-per-minute typing rate for core Unix commands, and pdmenu makes the blinky blinky cursor accessible to everyone. The horror! 😯

No more elitist machine-gunner hunt-and-peck console gurus while pdmenu is around. No more grand bearded Linux wizards, if triggering the application du jour is as easy as down-arrow-down-arrow-return. The knuckles will atrophy!

We all need our little spheres of control, I guess.

pdmenu will take you about a minute and a half to configure with the tools you prefer for text-only applications. If you can configure something like Openbox or IceWM, you can definitely handle pdmenu.

And best of all, you can whip the throne out from under your local condescending Unix computer genius. Here’s a nickel, kid. Get yourself a better computer.

Bonus: slmenu in action

There are very few things re: “life at the console” that truly surprise me any more, and even fewer that completely reshuffle the way I work on a daily basis.

But that stunt with slmenu from a few weeks ago has proven not only useful, but utterly addictive. If you missed it, here it is, animated.

Later on you can inquire after how I made an animated gif of my X-less desktop. If you ask nicely, I might tell you. Bribes are also accepted. 😈

Right now, try to focus on quick switches between programs, two-key and three-key startups without aliases, tab completion and so forth.

A couple of things have stood out since then.

First, the order of the items in the list makes no difference to slmenu. So you can arrange the order in any fashion, alphabetical or not, and slmenu works just the same.

You can also include aliases, scripts or commands nested in directories.

Again, slmenu doesn’t seem to care, and since you’re pumping it all back through to bash, it’s no different than a command typed at the prompt.

But best of all, it means you can stack your favorite programs at the top, and execute with Super_L and Enter. It’s almost a two-key macro.

I put alpine at the top of my list there only because it’s alphabetically first. but I also can fire it up immediately, at two keypresses.

For some applications, it’s only a little more inconvenient though. For example, it’s just quicker to type mc, than go through slmenu.

But for others, like some long-name applications, this is perfect.

If you haven’t tried it yet, give it a go. It might prove addictive to you too.

Now, about that gif … 😀

Bonus: slmenu, and some seriously wicked console wizardry

Whenever I use Musca, I learn to reappreciate dmenu.

You can keep your Unity, your Gnome3, even your gmrun or Kupfer. dmenu is a keypress and a half away and does only one teeny thing.

Too bad there’s not something like that for the console.

There is line completion, usually with the tab key. And some more advanced shells than bash do something similar to dmenu, I suppose, if you think about it.

Still, one keypress and a few letters to cue up the most popular programs on your computer … that might be useful, I suppose, if you think about it.

The suckless gang are rock-and-roll stars when it comes to featherweight software, so it should be no surprise that dmenu is in their stable.

Imitation is the sincerest form of flattery, and the author of slmenu acknowledges that a large proportion of its code was lifted straight from dmenu.

But slmenu, when prompted, looks … different?

What gives? Not much to work with there, K.Mandla! What’s it waiting for? Well, I can tell you.

Type in a couple of names of programs, then feed it the end-of-file key — CTRL+D.

Well, yes, that’s the general idea. Now you have a dmenu-esque line of applications that you can sift through either with tab completion or arrow keys.

But … that’s hardly helpful, you say. Who wants to type in the entire possible list of programs each time? That doesn’t just defeat the purpose, that’s the complete antithesis of what we’re chasing.

Fair enough. Suppose we had a list pre-made, with the most common software on the machine, in line-by-line format.

Would that do the trick? Now we just need to redirect that list back into slmenu, which is easier done than said.

slmenu < .progs.txt

Bingo. That’s exactly the behavior we’re after. So select a program and …

Crap. It just dumps the menu entry into stdout. It doesn’t execute it. Now how in the heck could we … wait:

eval `slmenu < .progs.txt`

Knock me over with a feather. It worked. 😯

But now … that is a heckuva line to have to type each time, just to get a single program started. You’re much better off with the original situation, you say.

True, but suppose we could create some kind of shortcut to that command … some kind of … alias. …

alias xe='eval `slmenu < .progs.txt`'

That should do the trick. I’ve been using xe because apparently nothing else starts with xe, and that’s sort of like “execute” in my mind. 🙄

Do that once and it’s good for your whole bash session. Drop it into your .bashrc and it’s there each time you log in.

Well, that’s nice, you say. But really, it’s still not very dmenu-ish. After all, you could just hotwire your entire .bashrc to cue your favorite software at a single character and an enter key, and skip the whole slmenu thing altogether. It’s just simpler to stick with the original, K.Mandla. 😐

All right. That stuffs it. The gloves are off. Here you go. Here’s the whole business, start to finish, cued up with one key press. Top this:

First we’re going to need a free key. Something that isn’t otherwise used by other software, and dedicate it to cueing that whole line, or at least the alias.

Lucky me, I have an extra key on my keyboard, painted with the logo of The Evil One.

The Microsoft key (or the Super_L key, or the Mod4 key, or whatever you want to call it) is tied to keycode 125 on my machine. I know this because showkey told me, when I tried it.

So now I need a copy of my console keymap, which is located in /usr/share/kbd/keymaps/i386/qwerty/, but is going to depend on your machine and architecture. Choose wisely.

cp /usr/share/kbd/keymaps/i386/qwerty/jp106.map.gz ~/jp106-SuperL.map.gz
gunzip jp106-SuperL.map.gz

Now we edit, adding these two lines at the end:

keycode 125 = F70
string F70 = "xe\n"

Save and close. On my Arch machine, only the root user can change the keymap, so:

sudo loadkeys jp106-SuperL.map

And there it is, with the -b option to force the display line to the end of the screen.

One. Key. Press.

Now you’re not allowed to complain about getting that into place or needing root access to assign a command to that keypress. And yes, I know it means any time your finger grazes that key you’ll get the slmenu display. Learn not to make that mistake.

And enjoy the one-key popup line-completion start menu you just installed for your text-only console system. Cue mad scientist laughter! 😈

As always, there may be easier ways or shorter aliases that will streamline this. And maybe there is a better way to put slmenu to use. Please let me know; I enjoy learning new tricks. 🙂