Tag Archives: network

rtv: Arr tee vee

And the hits just keep on rolling.


I’m only a lukewarm fan of reddit; it’s useful in some cases, but rather bewildering to me at other times, and I find the blind structure a little confusing.

All the same, we’ve seen reddit-specific console tools in the past, and ordinarily I’d step over something that was specific to one forum or site. But this seems particularly well done.

2015-04-15-6m47421-rtv-02 2015-04-15-6m47421-rtv-03

rtv claims to be compatible with a lot of terminal emulators, but my preliminary tests suggested it was quite comfortable with a framebuffer terminal too, and didn’t lose out any text or characters over font limitations.

Configuration is very straightforward, with a brief rtv.cfg file you drop into .config/rtv/ and edit with your account name and password (in plain text). You can also define a default subreddit (thereby avoiding unnecessary pictures of cats) and jump from subreddit to subreddit with the slash “/” key.

Right arrows open the discussion in a nested format, which is very convenient, and the “o” key will bounce you into your XDG browser. There are also keystrokes for refreshing a page, searching a page and posting a reply. If you’re a die-hard reddit fan and need something lighter than Firefox (what isn’t lighter than Firefox?!) to get your daily fix, this might be the droid you’re looking for.

Like I said, I’m not a huge fan, but I can’t mark down rtv for working specifically with a site that I am only ambivalent about — particularly when it does everything right. Beautiful color, very flexible display, easy controls and keystrokes with a visual representation that makes following discussions easy. Piece-of-cake configuration and on-screen help displays make rtv an clean sweep.

So here goes: ⭐ Don’t spend the whole day looking at pictures of cats, now. … 😉

P.S.: In AUR only, as both rtv and rtv-git. The -git version worked fine for me.


lancat: Zero-configuration network transfer option

Quick on the heels of pyncp, I got a short note about Graham Edgecombe’s lancat.

2015-04-08-6m47421-lancat-01 2015-04-08-6m47421-lancat-02

As you might imagine, lancat works a lot like pyncp, with a couple of exceptions. Yes, it’s intended as another fire-and-forget, zero-configuration network transfer option. And as you can see in the pictures (which I snapped a little too early), one machine “sends,” and another “receives,” and they listen for one another in the mean time.

A couple of small differences though. And not just that lancat is written in ruby, and pyncp was in python (and ncp was in C).

First, lancat is apparently desingned to work like a pipe, with your source file redirected into it on the sending end, and out of it on the receiving end. This might lend itself to use in scripts or with other tools.

Second, lancat’s function is determined by a flag, not by interpreting a command in sequence. That might prove more convenient, or at least quicker than typing out a full command for pyncp/ncp to interpret.

Aside from that, lancat works much as might be expected, but comes with the same caveats as pyncp did: There is no provision for security (or compression) unless to force it before and after.

But there are tools for that, and given that lancat handles pipes and redirects well, it shouldn’t be a big issue. 😉

pyncp: Quick and easy network transfer

This will be quick and easy today, since pyncp is a clean and straightforward tool.


If you remember waaay back, almost two years ago, we looked at ncp as a quick alternative for network file transfer. pyncp accomplishes much the same thing, but apparently sticks to python for its magic.

There are no exquisite flags for pyncp, but the program has to be installed on both the source machine and the destination. One machine “pushes” a file with pyncp push file.txt, and the other “polls” for it with pyncp poll. You don’t need superuser privileges or passwords — you don’t even need to know how to manage the network. One pushes, one pulls. Or polls, I guess I should say.

That’s it. If you want an encrypted transmission, I believe you might have to do that manually, and decrypt after arrival. Same goes for compression, but if you’re managing a series of file transfers over an open network, you should be doing those things manually anyway.

I only tested pyncp over my home network, so I have no guarantees how it will behave out in the wide open world. pyncp is in AUR as pyncp-git; my Debian search turned up nothing.

leo: Laid-back online learning

As online translation tools go, leo is doing a very good job.


leo is part of the WWW::Dict::Leo::Org perl package, and as far as I can tell, will only access the Leo dictionary site. For what I have seen of it, Leo works primarily into and out of German, with English and French as the main target (or source, of course) languages.

That does mean if you’re not interested in those languages, or if you’re working in a language that isn’t covered, leo might not be practical. On the other hand, it’s a good example of how a text-based online dictionary tool can work.

I’ve seen a few translation tools for the console, and the ones that worked weren’t terribly electrifying. leo seems to have a good grasp of how the output should appear.

Color is good, the table arrangement is easy to read, and aside from the rather wide dimensions, this is a good style for easy cutting-and-pasting. leo will take a term as a target or through STDIN, so you can pipe text into leo without disrupting the process.

Error handling seems a little primitive, since unknown words just trigger a 404 error message and a program line number. It seems like there should be a more graceful way to handle that. And leo doesn’t seem prepared to handle more than a single word at a time, which is a pity.

Otherwise I could find no issues in the way leo handled my requests. I like the way the results are arranged, and aside from a few funny glitches when I tried to pipe the results of the English-to-German results back into leo for German-to-French translation (I hoped to get English-to-French in a roundabout way), I couldn’t find any errors.

Debian users have the luxury of installing just libwww-dict-leo-org-perl to get at the leo executable; Arch users can technically get it from AUR, but you will need to update the PKGBUILD files for both perl-www-dict-leo-org and perl-html-tableparser and update the former to the 1.39 version. (perl-html-tableparser will work at the listed version, but I flagged it as out-of-date anyway.) It’s not too difficult a task, if you have a few moments to spare. 😉

httping: Lots of flash and dash

When I first read the description for httping I took it to be a ping tool intended specifically for HTTP addresses. I couldn’t really see how that would be terribly different from plain old ping, since I’m in the habit of just feeding URLs to ping anyway.


Oh, but this is something even better than that. :mrgreen: httping has a lovely ncurses mode that shows all kinds of flashy, splashy, dashy color and metrics. And manages to cram it all into one small display.


I have a lot of the fancier effects turned on there; if you install the FFTW libraries from your distro (fftw in Arch; probably something from here in Debian) you can play with the phase meter and traffic history bars too.

Or turn all that off and get just the plain ncurses display. Or just feed it an address with no flags, and get something a lot like straight ping. But where’s the fun in that? 😉

You could make the argument that pressing the phase display and the history graphs directly over the displayed text makes things hard to read, and I’d probably have to agree for the most part. However, I don’t remember too many other ping tools — or other network monitors, for that matter — that tried that, except perhaps for the venerable iftop, or its offshoot iftopcolor.

But personally, I like it. I think it works, and you have the option to remove it. httping is different, it’s colorful, it approaches a specific case and handles it completely but adroitly.

An easy decision: One gold star for httping: ⭐ Don’t spend it all in one place. 😉

connman and connman-ncurses: Pros and cons

These days I don’t have much installed in the category of “network connection manager,” even if I’ve seen plenty over the past two years. For a while I was a wicd fan, but the last time I checked wicd had stalled, and nothing really stepped up to replace it.

So in most cases, particularly if it’s not a terrifically complicated effort, I just use Arch’s wifi-menu or hand-manage connections with iwconfig and friends.

For an all-around suite of controls and connections, connman seems to do a good job. In its most primitive state, one-word commands will tell it what you want done with a network interface, and it’s more or less straightforward.

For a more replete user experience, connman-ncurses would be my suggestion.


That’s more to my liking. Straightforward keyboard controls and intuitive design, nice use of available space, and … well, I guess no color. 😦 But you can’t have everything. :\

Much of what connman-ncurses does can be inferred from onscreen tips, although I did refer to the git page once or twice, especially when I realized connman-ncurses (or probably connman) can disable your wireless at a keypress. And at some point, I must have pressed that key. 🙄

A decent addition to your text-only arsenal. Not in color, and with a few eccentricities to learn, but a lot of programs are like that. It’s worthy of a try or two. 😉

nap and nap: Take a nap or two

Two-for-one today, and not just because it’s 02-02, but because I have two programs with the same name, and I don’t think either of them really warrants an entire post to itself.

If you search both Debian and Arch/AUR for “nap,” you’ll find two different programs. The first, from Arch, is a variation on the sleep command, that shows a progress bar as it ticks away.


What you see there is really the grandest example of what I could do with nap, but that isn’t meant to suggest that it has no potential. If you search through this site, you’ll see that in the past two years, I never bothered to make any notes about the sleep command itself, because it was hard to think up something about a program that just waits.

nap does the same thing, but this time tells you how close you are to the end. If you want to know how much longer you’ll have to do nothing, nap will tell you.

The other nap is out of Debian, and is a console client for the now-ancient Napster file sharing protocol.


Unfortunately, that’s as far as I ever got with nap. Its self-configuration routine works fine, and I imagine if you could somehow force-feed it a list of servers, it might get further into its process, but I didn’t have any luck. It sat for the better part of an hour trying to download the server list from GotNap.com, and after that I felt pity and turned it off.

In any case, I don’t know what would be left on the Napster channels. I understand there is still some legitimate content operating under the same name, but whether this program can access it, or if this application is just lost in the dark ages of peer-to-peer networking … I can’t say for sure.

But that’s all for today. I see that my list is getting a bit short. I shall have to go out and beat the bushes this week, and see what falls out. … 😈