Tag Archives: menu

bashmount: Another seemingly roundabout solution

Mounting volumes from the console, without the need for background daemons or automounting tools, has been near the forefront of my Linux experience for years now. If it makes any difference, I’ve tried other options but still rely on mostly the same solution and setup that I did eight years ago.

Which could mean I am stuck in my ways, old-fashioned or just haven’t found a better solution yet. Or it could mean I don’t see any need to reinvent things — if it ain’t broke, don’t fix it. Adding a mount point to /etc/fstab and allowing any user to mount it seems to do the trick. I’ll let you know if it stops. 😉

It’s not a very flashy way to handle things though, and if you want something with a little more pizazz, bashmount might deliver for you.

2015-02-25-l3-b7175-bashmount-01 2015-02-25-l3-b7175-bashmount-02

As you can see, bashmount gives you a full array of attached volumes and their status, as well as options for even more information. A lot more than my hotwired solution, anyway. :\

And further, bashmount doesn’t need any fancy daemon packages or weird dependencies, and as far as I can tell, will do its job with only bash as a background framework. Supposedly it will work with udisks2, or some automounting tools, but I didn’t test it on that point.

Although it’s informative, and pretty, and colorful, and easy to use … I don’t think I’ll be adopting it over my home-grown solution.

For one thing, it doesn’t seem to eliminate the need for my fstab solution, since attempting to mount to an unlisted location triggers an error asking for root access. Well, in that case, it would just be quicker to su to root and do things manually.

So again I have a fairly clever tool that seems to do what it’s told, but using it implies a step or two in a roundabout direction before arriving at the same destination. Sort of along the same vein as xcv, which we talked about a week ago.

It may be that you can coax bashmount into avoiding those root permissions requests, or it may be that bashmount works as you expect without any heavy editing on your part. If that’s the case, I encourage you to use bashmount for as long as it satisfies.

I think I shall stick with my direct and straight solution. Not that bashmount doesn’t scratch the itch, only that there wasn’t an itch to start 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.

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

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

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.

2014-08-05-6m47421-percol-01 2014-08-05-6m47421-percol-02 2014-08-05-6m47421-percol-03 2014-08-05-6m47421-percol-04

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.

2014-04-21-6m47421-sentaku-01 2014-04-21-6m47421-sentaku-02

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 … 😐