nbwmon: An ncurses bandwidth monitor, of course

The world must have taken my abrogration of further text-based network monitors to heart, since we haven’t seen many of those lately. Here’s one that managed to escape my evil clutches: nbwmon.

 

And I’m glad it did. nbwmon has just about all the right moves: Color display, clean arrangement, adjustable refresh rate, automatic rescaling for peaks and valleys in the display, and so forth.

It’s all very nicely done. And dare I mention that it seems to hearken back to slurm and ifstatus? No shame in that. 🙂

I might have to close off this post early, because honestly, I can’t find anything wrong with nbwmon. Ordinarily I’d pick around and complain about this or that, but nbwmon seems as feature-complete as I’d like in a network monitor, without any shortcomings that I could find. No crashes (unless I resized the terminal to 12×8 🙄 ), no artifacts, no funky error messages.

So either nbwmon is almost perfect, or I’m losing my critical touch. Let’s hope for the former.

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

tty-clock: Taken for granted, for far too long

I casually mentioned tty-clock the other day while traipsing through ncurses-examples, then thought for a half a second and worried that I had never included it here.

A few panicked searches later and my fears were confirmed: Out of all the thousands (and yes, it has been thousands) of programs I’ve looked over in the past 20 months, I never gave proper attention to tty-clock.

That’s something we shall have to remedy.

I can’t think of a system I’ve built in the past five years that hasn’t included tty-clock. I’ve even patched it myself, a long time ago, before it was possible to feed a date format into the display.

tty-clock is usually what I hold up to other console clocks, and see how the fare. If a text-only clock can pass muster with tty-clock, it’s doing pretty well.

You can poke around with it on your own time, but know that it can handle multiple colors now, as well as bold effects, flashing time separators, seconds display, rebounding through the terminal window, 24-hour and/or UTC time, and refresh rates down to the nanosecond. It has evolved quite nicely.

Whether or not you prefer a text-based lifestyle and whether or not your computer can handle the burden of a fully graphical desktop environment, you really owe it to yourself to at least try tty-clock once. My apologies for omitting it for so, so long. 😳

Bonus: fbff, fbpad … and fbpdf too

I do feel obligated to list some framebuffer-specific software here, and I realized a week or two ago that my last list of framebuffer applications was not only almost a year old, but also omitted a worthy pair.

I don’t have much to show for fbff and fbpad, but they are both by the author of fbpdf, and mentioning one without the other two was an oversight. To complicate things, I don’t have a machine right now that will take faithful images of framebuffer output, so here’s my best effort at fbff, and to be fair, fbpdf.

 

Laughable, I know. Just don’t ask about fbpad. 🙄

fbff is probably my favorite of the three, as an alternative to running mplayer against the framebuffer. At 2Ghz on an ATI Mobility Radeon 7500 with an xvid-encoded avi file, the results were quite good. If you could see what it was showing, you’d be watching the opening credits for the first episode of season 11 of Gunsmoke. 😕 (Sorry, in my culture, people are mad for anything Western.)

And if you could see fbpdf at work above, it would be a classy black-and-white page with the words, “Sample text here.” I am nothing, if not inventive. 🙄

Please don’t blame the software for the shortcomings you see there. Both fbff and fbpdf accurately rendered the media against the framebuffer, and offered basic controls for each application. In spite of what you see above, they did actually work right. I just lack a proper screenshot.

fbpad was another issue, but that one was working against the clock for me. Configuring fbpad requires some heavy-duty font setup, the use of an outside font conversion tool, then editing the source code and recompiling fbpad to show the converted font.

I can’t say this is a better way than, perhaps, configuring fbterm. If you wade through those steps, show us a screenshot and we’ll all think highly of you. 😉

Dependency-wise, fbff and fbpdf were the heaviest, with fbff pulling in the ffmpeg structure (of course) and fbpdf requiring mupdf, some poppler and some djvulibre. If you have other options for video/audio/image playback and pdf display at the framebuffer, I’d recommend weighing them against what fbff and fbpdf will need.

fbpad didn’t strike me much heavier than fbterm, truth be told — unless you count the time and tools it would take to convert and configure and compile the font. And that, knowing full well I wouldn’t get a proper image of it anyway. 😦

One last question you might ask: So why make so much fuss about a couple of framebuffer-based applications? Well, for one thing, alternatives to the industry-standard tools, like mplayer or fbida, are always welcome. Neither of those is such a perfect fit for a framebuffer-only machine that someone new can’t wedge their way into my system.

Second, and probably more importantly, access to a framebuffer can sometimes be what saves a machine from the eternal reward. There’s a big difference between a 233Mhz machine that can run text programs fullscreen at 80×25, and a 233Mhz machine that can run a full suite of terminal applications at 1024×768 using the terminus font overlaid atop a picture of Miles Davis.

One is functional, but the other is crazy, funky and cool. 😉

irmp3 and irmp3-curses: All for naught

There’s a little clock in my head that starts ticking when I have been spending too much time trying to get a program to work. And that little clock was ticking furiously by the time I got this screenshot.

That’s irmp3-ncurses, a text-based front-end to the irmp3 audio jukebox. And believe it or not, after more than an hour of scraping around in two different distros, that’s the best I could come up with.

I am ashamed. My geek credentials are in jeopardy. 😦

As I understand it, irmp3 is primarily aimed at environments that need infra-red support or LCD output, so … car stereos, custom-built home mp3 players, and so forth. And if you skim through a few of these examples, it’s quite impressive to see what you can do with it.

Unfortunately what I did with it … was almost zero. I could build both the daemon and the command-line control interface in Arch. I even managed to generate a configuration file with the built-in utility, but the daemon never seemed to find my music path, which meant the command-line interface couldn’t tell it to start playing, and irmp3-ncurses couldn’t help anyone out. Not even with alsa-oss on the team. 😦

So I switched to Mint, because the previous verision of irmp3* is in the Lucid (and Debian Squeeze) repositories. If the issue was a faulty setup in Arch, perhaps the Debian/Ubuntu versions carried enough default settings to get things rocking. But as luck would have it, the Mint/Ubuntu version was no more successful. Oh well, I tried.

There are a few considerations, of course: The last version was released way back in 2007. I don’t have either LCD or IR hardware. And I have a long-standing reputation for butchering application conf files. Any one — or all — of those could be the problem.

If you know how to get this one working, or if you have tips on how to make it sing pretty, or if you converted your 1949 Citroën 2CV into an mp3 player with irmp3, please help us out. Science demands an answer. 😉

gplayer: Get loud with the cloud

It seems cloud-based or Internet-heavy tools are the choice of the gods of shuf today, since the second title for this sunny Saturday is a CLI-based interface for Grooveshark, the online streaming audio service.

Like I said earlier this week, I’m in favor of any utility that strips away the worthless scum that coats most Internet services, and I list the noxious, fetid remains of Flash technology among that. So from the start, gplayer wins points for allowing me to sidestep the standard Grooveshark player.

That said, gplayer doesn’t reach the same degree of finesse that soundcloud2000 did. It is worth remembering that what you see in the screenshot is accomplished in approximately 60 lines of code … of course, allowing for the fact that mplayer, that seven-headed-ten-horned beast of media playback, is doing all the heavy work.

It’s still impressive though. gplayer gives you a search function that mimics Grooveshark, returns a list of 20 results, and allows you to cue any of the titles that are listed. From there, mplayer takes over, using its keypresses as controls and its frame progress counter as an onscreen display.

I’ve found a few small incongruities in gplayer, and I’ll note them here just as a matter of record. For one, when a song ends either because it’s over or because the listener gave “q” to mplayer, gplayer never recovers its prompt. I get a dull cursor without any text, and short of pressing CTRL+C, gplayer seems to have stalled.

I don’t think that was the way the author intended, since it would make more sense to me, as a casual user, to either get a new search prompt, a prompt to cue another title, a repeat of the previous list, or just be dropped to the shell. As it is, I’m lost somewhere betweem mplayer finishing and gplayer recovering.

Second, it’s fairly easy to send gplayer into a tailspin over the selection. Any non-numeric character will cause an error, and any out-of-range of numbers will cause an error. It’s just an issue of trapping those entries and preventing gplayer from exploding across the screen.

I can stop there since that’s about the limit of gplayer’s functions. If you’re willing to hold its hand for a little bit, and if you can find a way to cue up several songs in a row, and if you’re a fan of Grooveshark in the first place, you’ll probably find a place in your heart for it.

Oh, and I think the author should follow soundcloud2000’s lead, and subtitle gplayer as “Grooveshark without all the stupid css.” Or maybe “without all the stupid Flash.” 😉

googlecl: Cutting corners with everything Google

My office uses Google Documents for almost everything it does. We all have GMail addresses and even our primary site is managed through Google, although the intricacies escape me.

I concede that it does streamline some things, but only because I have to. I’m still no fan of the cloud, and I never have been, and probably never will be.

Having said all that, I can see where googlecl would be very, very useful in our office for bulk management of e-mail lists or contact information. Just as a very brief example:

 

That’s the same example that appears on the home page, so I suppose pixellating much of those images was unnecessary. All the same, I think you should get the point. With something as simple as google contacts add and a little data, I get a corresponding addition to my online Contacts list.

Which is what you would probably expect. And it likewise goes without saying that googlecl can handle not only GMail Contacts, but also Blogger posts, YouTube uploads, Calendar events, additions and edits to Documents, and just about every other aspect of your collective Goo-perience, from the command line.

I can’t go into too much detail on invididual commands and configuration, mostly because each Google aspect has its own rasher of options and specifics. If you’re genuinely interested — and again, for my daily workload I already see a few places this can be useful — you’ll need to look closely on your own.

Probably the one thing I like best about googlecl is what you see in the terminal screenshot above: Rather than require a configuration file setup, googlecl simply links you to the API authentication page, and prompts you for the passcode. It does save a step, and gets you moving a little faster with the entire Goo-perience.

And I tip my hat to that. I never have and never will concede my own private and personal information to The Almighty Cloud, and have serious worries on behalf of anyone who does. But I’m taking this to work on Monday, and seeing if it will help cut a few corners. 😐