cloc: Clock your code

Line-counting utilities are not a new thing for K.Mandla; there have been a few of these available for a while. codemetre comes to mind, as does sloccount. Even wc could fit in that category.

Here’s cloc:

2014-07-28-lv-c5551-cloc

cloc has a couple of features I like. For one, cloc can work straightaway on a compressed file. You don’t need to extract an archive before cloc does its thing; cloc will handle the decompression automatically. And if it runs into trouble, you can assert your biological superiority and tell it which decompresser to use.

cloc also has some built-in diff tools, which might not sound like a wonderful idea at first. What that means though, is that it can look for differences between versions of programs, and report on those. This might be useful if you have an axe to grind with a developer. >:(

And cloc carries a lot of filtering options, on everything from regex strings to specific programming languages to hidden Windows files. That might have saved me a little time when counting lines in the 3.15.6 kernel, above. :|

The sad part of this little exposé is that I have so very, very little coding ability that cloc (or for that matter, codemetre or sloccount) isn’t something I’ll likely use. Unless, of course, I’m counting lines of text in a smarmy blog. ^^’

column: With oddly satisfying results

I’m going to stick to the C section for a day or two, and hopefully whittle down the disproportionate number of titles I have listed there. I’m not sure why, but it seems that between October of last year and now, I managed to collect 30+ titles in the C section alone. And it hasn’t helped that ls vimwiki/ | shuf -n1 kept pulling stuff from outside that band.

column is on the list, and is something I use on a weekly, if not daily basis. Here’s column, in its most daring escapade yet: :roll:

2014-07-28-lv-c5551-column

And the attraction should be immediate. If we’re going to talk about tools that improve readability, column needs to be at the top of the list. Even when combined with yesterday’s deluge of colorificated diff tools, column makes things better.

2014-07-27-lv-c5551-wdiff-colordiff-column

It’s not always perfect, but I have a feeling that the escape sequences used to trigger colors might interfere with the final results. No major loss.

The point is that column, by default, and especially when used in conjunction with the -t flag, is going to be a real improvement for scanning lists of data and finding corresponding entries. Keep that in mind next time you’re working with csv files.

column takes very few options, and in general they are only affect how the rows and columns are generated, or determining display width. You won’t find a whole lot of frills with column, even if it does amazing work.

I know what you’re thinking at this point: You’re imagining that a utility as simple and cool as this could only come from one place — coreutils. Surprise: This appears in util-linux in Arch, and bsdutils in Debian. :shock: O_o Why? IDK. IANADD. :D

wdiff, cwdiff and dwdiff: Since I mentioned it. …

I just mentioned colordiff, but left out one thing it can do: colorize the output of wdiff. And what is wdiff, you say?

2014-07-27-lv-c5551-wdiff-colordiff

That should give you an idea. wdiff works in the same way as diff, but at a word-by-word level. If you look closely in the upper half of that image, the differences in lines of text are offset with brackets and curly braces.

That may be enough for you, but you have to admit that the second half, where the output was piped through colordiff, is much easier to scan. The man page says you should add -n to wdiff before sending it through colordiff, but as you can see there, it worked fine in that example.

wdiff works well with colordiff, but you might prefer cwdiff, as opposed to piping things through one another.

2014-07-27-lv-c5551-cwdiff

cwdiff does much of what wdiff + colordiff offers, and simplifies the process quite a bit. There are a few added options too, including one to subtract the color from the output — meaning you get pretty much what wdiff had originally.

By default, cwdiff’s output is simplified somewhat from what wdiff creates, or what wdiff produces through colordiff. It’s not necessarily better, but it is a tiny bit … different. :roll:

dwdiff is the last on the list that I feel obligated to mention at this point. By now, you’ll probably feel like dwdiff doesn’t really do anything that wdiff, colordiff, cwdiff or even just diff could handle.

2014-07-27-lv-c5551-dwdiff

dwdiff also plucks out differences between words of files, and has a -c flag to inject color into the output. The distinguishing point between dwdiff and the others, as I see it, is its ability to set specific delimiters while searching.

I couldn’t think of a good case example for that, and I searched around in hopes of finding something to test it. Nothing handy appeared though, and most examples for dwdiff seemed to generate the same output as wdiff alone or cwdiff might get you.

So the final questions become academic: First, do you want colorized output (say yes! say yes!); and second, do you need control over specific delimiters when comparing files?

If you answer yes to the first, cwdiff might be the best tool, although you can get the same results from wdiff alone if you have colordiff available. If you answer yes to the second, you’ll most likely want dwdiff regardless of your preference for color.

And if neither of those questions is important … well, then you can probably get through the day with just the original diff tool. No shame in that. ;)

colordiff: A difference in color

Remember my unnatural predilection for anything in color? You have to admit I’m right on this point. After all, which would you rather look at?

2014-07-27-lv-c5551-colordiff

At the top, diff. At the bottom, colordiff. The choice should be an easy one.

The man page describes colordiff as a perl wrapper for diff, and that’s very true. As a matter of fact, it’s so tightly wound around diff that if you ask for colordiff --help, you get the output from diff --help. :???: And I know there’s no difference because I used colordiff to show the difference between diff --help and colordiff --help, and there was no difference. See what I mean? :?:

2014-07-27-lv-c5551-colordiff-diff-diff

Clear as mud.

colordiff has its own rc file, installed by default at /etc/colordiff in the Arch version. I would advise you to copy that into .colordiffrc, and customize the colors there, but if you’re just one of those weirdos who runs a black-on-white terminal emulator, you’d do just as well to copy /etc/colordiff-lightbg into your .colordiffrc file instead.

That’s about all I can think about with colordiff. It stays very tight to the original tool while still giving you a small measure of customization, and that will probably keep you happy in your pursuit of differences. ;)

cliwiki: Needing attention

I try to be as honest as possible when I look over software. If it seems like I’m too-often enthusiastic about programs, it’s probably because the ones that were less than gratifying were cast aside out of frustration.

I’ll list cliwiki though, since I sense it has a little potential, and a tool that pulls pages from Wikipedia is worth pursuing.

2014-07-26-lv-c5551-cliwiki

I don’t recall where I got the link to cliwiki, but my assessment is that it needs more attention. Here’s why:

  • The few arguments cliwiki claims to support produce nothing. The home page suggests potd, featured and onthisday, but none of those generates any different results.
  • cliwiki requires you answer a prompt to trigger the search. You can’t tack on the topic as a command line argument.
  • cliwiki incorporates no pager, and because of the prompt, it’s exceedingly difficult to page or redirect the output of very long pages.
  • Because of those shortcomings, I’ve tried to funnel cliwiki into text files with the standard > mark or a pipe symbol, but the prompt confounds things. I get half-formed pages or worse, lockups. For what it’s worth I’ve also tried to echo my search topic into a text file and use < and xargs in one fashion or another, with no real success.

All of this means to me that cliwiki is only half-formed, and partially useful on pages that don’t overflow your terminal window. I daresay on very shallow screens it will be nigh-on useless.

cliwiki does do some things right; I like that it lists links at the end of the page, and adds links to images in the text. But cliwiki still needs a bit more work before it’s functional, either to the degree it promises or to a point of usability.

jrnl: Focus, grasshopper

Now that I think about it, I haven’t seen many journals or diaries during this little adventure. It may be that they fall into the note-taking bracket and are relegated to text editors, or it may be that you see your old calendar entries as a journal of sort.

Seeing jrnl might change your mind.

2014-07-26-lv-c5551-jrnl

jrnl is going to win some points from me for a lot of different reasons. For one thing, adding an entry is basically how it would happen with pen and paper: jrnl yesterday: I sold the farm. It’s very simple.

More complex entries are possible, and for that, jrnl jumps to your $EDITOR. Don’t ask me why, but I always find it appealing when a program allows you to stick with the editor (or pager) you know, and is already part of your system. That makes it easier for everyone involved.

And even if you aren’t a fan of your own $EDITOR (in which case you really should set it to another O_o ), you can just redirect a text file back into jrnl, a la jrnl < boastful-event.txt.

Showing your previous entries is a breeze, with the -from and -to flags for date matching, plus the ability to add tags preceded with an @ sign. From there, you can filter by topic. Very clever.

You can also star entries, for particularly exciting moments in your past. And you can encrypt a journal to keep it from prying eyes. And you can export it to markdown (and thence to HTML, meaning you can plop your journal into a rancid little blog or site :\ ) or json, and dump the journal into a folder with individual files for each entry.

jrnl has all the hallmarks of an application that was well thought out and designed to meet include specific abilities. Sometimes programs are organic collections of scattered features, obviously added as time went on or as the public suggested them, and without any focus.

I don’t get that feeling from jrnl. This has the distinct impression of having a specific end in mind, and the features it offers work very well together. I like it for that. :)