greg: You’re so vain

Everyone named “Greg” out there in the world can now sit up straight and imagine this little program is named in their honor.


I was introduced to greg after yesterday’s note about podcastxdl, and in spite of its lack of color and command-action-target input style, I think I like it better than the latter.

Of course, that screenshot isn’t very interesting, but what you see there is a lot of the way greg works. It maintains a list of podcasts and addresses, and you can wrangle them with fairly straightforward actions.

greg add adds to that list. greg remove drops it off, after you confirm it. greg check sees if anything is updated, and greg sync synchronizes your local folder with what’s available online. Like I said, it’s fairly straightforward.

I don’t see anything offhand that disappoints me about greg. I ran into no errors except when I fed it an invalid link, and it warned me that it wasn’t going to work. And aside from the lack of color and lack of an “interface,” it seems to work perfectly without my empty-headed suggestions.

So there’s greg, which we can add to the meager list of podcast aggregators for the console. Now do you see it? “greg”? “aggregator”? Aha. … ;)

podcastxdl: One-shot downloads for your ears

There are not many podcast tools I can mention, in the years spent spinning through console-based software. In fact, I can think of only about four. But here’s one you can add to your list, if you’re keeping one: PodcastXDL.

2015-04-19-6m47421-podcastxdl 2015-04-19-6m47421-podcastxdl-02

PodcastXDL works in a similar fashion to podget, which you might remember from a looong time ago. Give PodcastXDL a url and a file type, and it should parse through the stream and pull down everything that matches.

It can also spit out links, meaning you can use PodcastXDL to supply links to files, rather than download them. There are also command-line options to start or stop at specific points in a feed, which might be helpful for cropping out older files.

I’ll be honest and say I had a few difficulties working with PodcastXDL, most notably that it didn’t accept my target download directory. If you run into issues with PodcastXDL and nothing seems to be arriving, I would suggest leaving off any -d argument.

Other than that small hiccup, PodcastXDL did what it promised, and I ran into no major issues. It has good color, plenty of options and has seen updates within the past month or so, if you shy away from dated software.

If you need something quick and one-shot for podcast downloads, this could work for you and is better looking than podget was. If you’re looking for something more comprehensive and with more of an interface, stick with podbeuter.

ncdt: An interesting evolution

Quick on the heels of tree and ddir, a loyal reader pointed out ncdt, which takes the tree model and adds a small feature or two.


As you can see, ncdt adds the size of files and directories as part of its default display. So in situations where it’s useful to see directory structure and size — such as labeling removable media, like CDs — it is probably more useful.

Unfortunately, I see no options to adjust what ncdt shows, so there are no “human-readable” (which I prefer) output flags or the like. What you see is what you get.

ncdt also promises to show “special” data for mp3 files, but the Debian version as well as the version I built on my Arch system from the Debian source package showed nothing. Even the sample screenshot in Debian doesn’t show anything “special” for mp3 files. Hmmm. :(

It’s possible that there is an added dependency that I don’t have, or perhaps the mp3 files I tried post-date what ncdt is capable of analyzing. I checked the ReadMe and source files, but I got no hints. And the only home page I have for ncdt is the Debian package page above.

No matter. ncdt adds a little to the tree model and could probably, at one time in the past, show a little information about mp3 files. It’s an interesting evolution, even if it still needs some attention to reach fruition.

shpaint: For the Toulouse-Lautrec of the terminal

Part of the fun in spending two and a half years sifting through random text-based software has been the occasional joy in finding something amazingly cool. On occasion I’ve stumbled over stuff I didn’t even think was possible, and yet there it is, in plain view.


That’s Martin Bruchanov’s shpaint, which is a simple, mouse-driven ANSI art editor for terminal emulators. You can probably figure out how to use shpaint just by looking at that screenshot; click on a foreground color, a background color and a glyph, and click away until your artwork is complete.

It’s all the more impressive when you realize it’s written in bash. And to really blow your mind, Martin points out that it’s done in only 180 lines of bash. :shock:

If I have 180 lines to work with, I’m lucky if I get “Hello, world” to appear on the screen. :\

shpaint isn’t perfect, but that doesn’t detract from its coolness. For one thing, it doesn’t work in a virtual console; I tried to fire up gpm and draw my rendition of the Mona Lisa (imagine a stick figure in garish colors), but apparently shpaint doesn’t work that way.

shpaint also can’t really do more than plot a glyph at a time. No line functions or paint-fill buckets. You have to do this old-school, like we used to do things back in the 80s.

Martin admits that occasionally something goes haywire between shpaint, bash and the terminal emulator, and clicking a cell will cause weird and random painting effects. That happened to me once or twice, but the fix is easy — just exit shpaint with CTRL+C, which saves your file automatically, then restart it and all is well.

shpaint sends your rendition of Whistler’s Mother to a flat file that will spill out the same image just with the cat command, meaning you can probably work this into other, more advanced editors to handle more intricate touchup. Don’t feel guilty doing that; our artist at work regularly sketches with a pencil, then scans her work into a computer and does everything else in Photoshop.

In fact, I’m no Picasso, but I daresay there are probably some parts of text-based artistry that would be well-served by relying on shpaint as an option to aewan, cavewall or duhdraw, even if it’s just for the speed of plotting points with the mouse, as opposed to cursor controls.

shpaint wins points from me just for being amazing and cool, but also for doing its job cleanly, obviously and without unnecessary bloat. I know this technically falls down on some of the points I like to see in text-based programs, but I think it deserves a star anyway: :star: Give it a try. ;)

goobook: Command-line contacts

My workplace relies heavily on Google Documents and GMail right now, and so something like goobook should come in handy.


What you see there is very primitive, but as I understand it, goobook is mostly intended as an ancillary tool for mail agents, like mutt or perhaps alot. Adding goobook to those tools means you can manage Google contacts without the need for a browser as an intermediary. Which is always a good thing.

goobook needs a little configuration before it can get started; at the very least, you can add your e-mail address and password to .goobookrc, and if you need more help than that, It will generate a template for you with goobook config-template > .goobookrc. I was able to get to most of goobook’s functions just by uncommenting and editing two lines in that file, although the help pages show how to properly encrypt your password and so forth.

From there, you should be able to build your local cache (or refresh it) with goobook reload. Adding addresses works with goobook add, and so forth.

goobook probably looks simple and for what I’ve seen, it is. But I also feel like the usefulness with goobook is in splicing it with your mail client. So don’t mark it down just for seeming basic. That’s probably intentional.

goobook is in AUR in several flavors; I don’t see this in Debian but I don’t think it would be hard to add by hand. :)

textprint: Visually impressive, in only 18K

You can get graphing and plotting functions in the console from a variety of sources. textprint is easily my favorite for simple data arrays, mostly because it can do this, with only 18K:

2015-04-16-6m47421-textprint-01 2015-04-16-6m47421-textprint-02 2015-04-16-6m47421-textprint-03

textprint takes a flat data file as input, and arranges it graphically to fit the terminal without distorting the image. From there, textprint goes from zero-to-60, in about two seconds.

Because on top of a rather bland plotting display, you have the option to pick between about four or five different graphs, including the bar and column charts you see above, and a couple others.

And then, you can shift those displays along the x or y axes, zoom the displays and even “print” the display to a text file that matches what you see on the screen. (I did see some corruption when trying to zoom in too “close,” though.)

So you have essentially a tool to convert data arrays into visual representations, adjust them to your liking, then “print” them in their new format. And all that in only 18K.

textprint is not without shortcomings, but truth be told, I could sift through anything and find small nits to pick at. Color options would be nice, and while it does have onboard help, there aren’t any flag options that I can see. If I could send commands to textprint and have it spit out a “printed” file without the interface, textprint would be doubly useful.

And to be honest, the title “textprint” is a slight misnomer. That’s going to get lost in the endless array of pdf converters, ASCII readers and document translators that already pepper the ‘web. It needs a more accurate, and more descriptive title.

It’s still exceptionally impressive though. And the fact that it has so many options in such a small space. And seeing that it’s a dozen years old and still working is noteworthy too.

Not in Arch/AUR or Debian that I could find. textprint is bundled with a precompiled binary, but it’s going to look for an ncurses library that didn’t exist on my Arch system. The command to compile it is in the readme.txt file.

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: :star: 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.