since: Since you last checked

I promised I would get since onto these pages before the end comes, mostly because I don’t remember any other log viewer that has this behavior by default … and I want to be able to remember it in the future.

2015-04-26-6m47421-since

It’s hard for me to be sure though, after so many years and so many log utilities. :\

since seems different because, as you might have inferred from the screenshot, it only displays log data since the last time it checked. So you can see the last portions of pacman.log at the top of that image, then the repository update. The next invocation of since only shows the two lines that had been added.

I’m sure other tail-esque tools can do this, and possibly add a few nifty tricks in passing. It’s just a matter of finding the right flags and getting them in order.

For its own part, since keeps its state file in ~/.since, and you have the option to ignore it. You can also tell since to use a special state file, to run periodically, to ignore compressed logs, ignore missing logs, and a lot of other options.

I am not a real bloodhound when it comes to keeping an eye on logs, so at its best, since is useful … but only rarely. On my pseudo-desktop system, there’s almost no call for it.

On a more complex system or in a situation where log files are critical, it might save you some time trying to get the information you need. I’m willing to give it a thumbs-up. :)

rfc and httpdoc: Two terminal references

I have a couple of simple but related tools today, both from the same author. At left is rfc, and at right is httpdoc.

2015-04-25-6m47421-rfc 2015-04-25-6m47421-httpdoc

I’ve known about rfc for a while, but got a reminder about httpdoc earlier this week via e-mail. Since they both have the same style and same creator, it makes sense to lump them together.

rfc, when supplied with a number or a topic line, will pull the text of that RFC from the web and dump it into your $PAGER. No fancy formatting, no color-coded document histories, just one-shot quick access to RFCs all the way back to … well, back to number 1.

The home page has a three-step process for “installing” rfc into your $HOME directory, although I daresay it could be rearranged to allow for more than just one person to use. In any case, it takes very little effort and rfc itself won’t bog down your system, seeing as it’s just a bash creation.

As an added bonus, rfc will keep its documents stored locally, so you don’t have to re-download a request. If you rely on rfc frequently, you’ll probably be interested in some of the built-in actions — like update or list, which give rfc a little more oomph, and search, which … well, you should be able to figure that one out. :roll:

httpdoc is similar, in a way. As you can see above, httpdoc becomes an offline reference tool for HTTP documentation. In the screenshot above, I only showed the 404 status code, but httpdoc can also return documentation on header fields, if you need that.

I can see where httpdoc is still being updated even in the past few days, so I expect there will be more references to come.

httpdoc is written in go, so you’ll need that installed before it will play along. There are also some environment variables that you’ll want to adjust before using it, but it’s nothing complicated.

Both of these tools might strike you as too simple to be noteworthy, but that will depend a lot on your perspective. I use things like dict on a daily basis, and even have it hot-wired for thesaurus entries as part of my .bashrc.

If you have a similar need for RFC or HTTP documentation at the command line, then you might find both of these install-worthy. Necessity is the mother of invention. Or is it the other way around … ? ;)

undistract-me: Quashing your ADHD

I fear this little utility might be usable only for a discrete set of fans. Technically speaking it’s a text-based application, but … well, I’ll let you take a look and see what you think.

2015-04-24-lr-0xtbe-undistract-me

In principle, it’s rather simple: undistract-me simply takes note if a shell command takes longer than 10 seconds to execute. If it does, it waits until the program finishes, then throws up the alert message you see in the screenshot above. Kind of cool, in an odd way.

Strictly speaking though, you’ll need all the underpinnings of a graphical desktop, plus whatever alert system is in use there, before you’ll get close to that kind of behavior. On my semi-graphical Arch system with just Openbox, I ended up adding gtk3, polkit, dconf, json-glib and a mess of themes and libraries before the git version was close to running.

So I don’t know if I’m being fair by including it. Don’t expect to suddenly plop this into place on your 400Mhz Celeron running screen, because you’re going to need a lot more to get close.

I won’t deny that I like the idea though, and if something comparable could be implemented in a text only environment, it might be worth trying. For my own part, I used to append long-running commands with aplay yoo-hoo.ogg so I would get an audible when something finished.

So in that way, I can sympathize. But unless you use a lot of terminal commands on a Linux Mint desktop and need some sort of blinky reminder when one finishes … well, like I said, it will probably only appeal to a slim range of fans. :\

rmlint: The potential to purge

I am behind the power curve today, because of some real-life obligations. I am going to grab something quick and easy so as not to fall behind; things are going to be even busier into the weekend.

This is a snapshot of rmlint in action:

2015-04-23-l3-b7175-rmlint

rmlint cruises through your directory tree, and offers to remove files it thinks are duplicates, zero-byte or hollow folders. And as you can see, given enough space, it will take its time to come up with a menu of potential excisions.

I did say “offers,” which is an important distinction. rmlint’s output is a little unexpected: By default it generates a script that will remove suspicious targets, but doesn’t outright eliminate them.

Which is a good thing; it means you have the option to adjust its list, and it also means you take the next step — running the script — with conscious aforethought. You can’t blame rmlint for whacking apart your /usr/lib folder if you told it specifically to do it.

I like rmlint for a number of reasons — it’s rare that I see a system cleaner, it takes the safe route by creating the script, and it has a smidgen of color.

But that’s about all the time I have today; I’ll get deeper into something tomorrow … I promise. ;)

x_x: The Dead Guy CLI

With barely a week left for this site, I’m beginning to trim away programs that I just probably won’t get to, by virtue of time or technical dilemmas. I’m also making a conscious effort to pick out titles that amuse me in one form or another, so I finish with happy memories. :P

x_x, which I mentally refer to as “the Dead Guy CLI,” because the home page uses that as a subtitle, is a rather nifty tool that I’m surprised I haven’t seen covered elsewhere. Using a bland, dull, boring Excel spreadsheet borrowed from a corner of the Interweb, Dead Guy CLI transmogrifies it into this:

2015-04-21-6m47421-x_x

Well isn’t that clever.

Dead Guy CLI gives you a small measure of control over your output, by allowing you to specify a header row or allow for special encoding. It also works with CSV files, so you’re not strapped trying to convert back and forth to Excel, just to fiddle with x_x.

Aside from that though, Dead Guy CLI seems very simple. Of course, your spreadsheet may need some management if you expect it to fit into a certain dimension, but I am confident that as a skilled and capable member of the information age, you won’t throw a wobbly over a pear-shaped spreadsheet.

Keep x_x in mind when you’re thinking about things like csv2xls or xlhtml, since it may save you a step or prevent you from relying on graphical tools just to extract data from a spreadsheet. And of course, if you’re working with csv files, x_x could supplement what tabview or other tools can do.

For my own recordkeeping, Dead Guy CLI gets points for doing something obvious that I don’t recall seeing elsewhere. And also for the snarky name. I’m a fan of snarky names. :twisted:

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.

2015-04-21-6m47421-greg

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.