colormake: Does what you’d expect

On the one hand, I can admire colormake for its simplicity.

On the other, that’s about all it does. I will grant that colormake does convert make’s output to something more readable, but I also have to admit that the color doesn’t do much to help me understand what make is saying. 😦

Calling colormake is not particularly different from using make itself; you can apparently use it in almost every case where make is used. Even asking for help with -h or --help sends that request straight through to make, and you’ll get make’s quick help listing.

Which means if you want guidance you have to go straight to the man pages. And for what I’ve seen, there’s only one flag you can give colormake, which specifies an exact makefile, as opposed to just Makefile, I believe.

colormake is in Debian and AUR, but I see some differences between the two that suggest the Debian rendition hasn’t been updated. The only colors I saw in the version yanked from Debian were white and cyan, but the AUR version pulls its source from Github and was much more colorful.

I feel obligated to mention that there is an identical (knockoff?) project in Daniel C. Jones’s namesake program, the main difference being the use of python, I believe. So hey — two-for-one today! 😀 🙄

icdiff: Visibility by default

I have just enough time this morning to scratch out a brief note about icdiff. We went through a lot of diff variants over the summer, and for every one of those there was probably a colorizing tool that could pick up the visual slack.

That might be the strongest point for icdiff: that fact that you get most of the best features of conventional tools like diff proper, plus a healthy degree of control available in tertiary colorizing tools.

 

I have two screenshots there because it might be important to you to know that, by default, icdiff is going to abbreviate its output to show changed areas and their context. This took me a minute to figure out, since my original file had 52 lines or so, but icdiff kept showing a much shorter output.

The --whole-file flag is what controls that, and there are quite a few other options worth mention. icdiff has a built-in head feature that constrains the input to the first x lines of each file, which may be useful as opposed to piping both files through head before handing them to icdiff.

Another point that might interest you is the --highlight flag, which colorizes the background field instead of the character shape itself. The author suggests it’s ugly but fast; it caught my attention because it was much easier to spot single-character changes with this.

icdiff is in AUR, but I didn’t find it in Debian. Users of either distro (or others) should be able to get it working from its git repo though, so feel free to try it out.

icdiff is a decent tool with some good features and might be more accessible to casual users — like myself — as opposed to the classic diff or simpler attempts to colorize it. It’s rare that I need a diff tool but I can see where this one would come in handy.

lolcat: From the ears to the eyes

That last note about jdkdrum was missing a visual element, so I hope this one — lolcat — makes up for it.

From what I’ve seen, that’s about all that lolcat does — paints your emulator output in rainbows. Not that it’s less than expected, only that it might disappoint the terrifically serious types in the audience.

But that does mean it’s really just a cat tool … with the obvious addition of lol. 😉

There are a few options available to lolcat, and they either enhance or control the rainbow output that you see up there. There’s also an --animate flag that will cause each line to pulse through a rainbow before moving to the next … sort of like the old Atari computers used as video output. If you remember those days. 😕

I should mention that lolcat’s output is quite different from toilet‘s “fabulous” mode; if you look closely at the respective screenshots, you can see that each character in toilet’s output has a single color.

But lolcat is painting its output across individual characters, which is rather interesting. 🙂 lolcat will work in a virtual console, but you don’t get the same smooth rainbow effect. In fact, lolcat in a vc performs a lot more like toilet does.

lolcat is in AUR and is listed as on-deck for Debian Jessie, but both versions seem to come with a wicked mesh of ruby dependencies. If you’re expecting to just throw this on your old 300Mhz Pentium II laptop and start lolcatting news updates from across the web, there will be some patience required.

Ah, but the final product will be worth it, don’t you think?

grc: More colorizing for terminal output

I really should have sifted through the titles I had waiting back in June, when I finished the alphabetical sequence, and plucked out all the colorizers. I’m still finding them, months later. Like sand in my shoes after going to the beach. 🙄

Here’s grc, which is a lightweight colorizer for common terminal commands.

 

grc works on the same premise as some others we’ve seen; there is a shortlist of commands it knows and can colorize, but beyond that you’ll need to roll up your sleeves.

For what I see in the Arch version, which installed color profiles to /usr/share/grc/, grc can handle configure, cvs, diff, dig, esperanto (?), gcc, ifconfig, irclog, ldap, log, ls, mount, mtr, netstat, ping, proftpd, ps, traceroute and wdiff by default. So as you can see, it isn’t limited to commands.

I was going to question the logic of a few of those additions — mostly ls — because they already have color options. But this is oh-so-lovely. …

Which just goes to show that there’s nothing that has been done, which can’t be possibly done better. Nice work.

If grc encounters something it doesn’t know, you get the program’s natural output, uncolored and as best I can tell, unchanged. So you might be safe using grc within an alias, and just calling for it as part of your daily routine. I like the idea of seeing that grc ls -lha all the time. … 😀

Diving into grc won’t cost you much in disk space either. The tarball is barely 25K, and even when packaged, you’re talking about possibly 27K, for example, for the Debian version.

What’s clear at this point is, I need to find a way to distinguish between programs like grc, which colorize specific output, and color filters that pluck out specific words and add color to them. Not like it would matter though, since I’d be the only one making that distinction. …

acoc: More filter-based colorizing for the terminal

I had some personal issues that needed attention yesterday, so I didn’t get the chance to post anything. I’ll make up for it today though; here’s acoc to start us off right.

My “week” of output colorizers never really ends. 😉 acoc works in a similar fashion to colorwrapper and rainbow, by using command-specific filters to predict and assign color to a program’s output.

That means acoc has specific programs that it knows how to colorize. It’s not a grep-ish tool like colorex; instead it’s looking for specific output from specific programs. In some cases that’s prefereable, in others it’s not. It will depend on what you need a colorizing tool for.

Right now, acoc’s list of recognized commands is somewhat small. There are about 30 here, and perhaps six to eight of those are distro-specific. There’s also an added complication that some of the commands don’t seem to produce any color with acoc, which might mean it’s looking for something different from what my Arch system can produce.

acoc allows for custom filters, and the syntax appears to be fairly straightforward. So if there’s something that you need and acoc doesn’t support it out-of-the-box, you can build it in a few minutes.

Altogether, acoc reminds me of colour more than anything, since it too will probably require a little attention before it meets all your needs. acoc definitely has more filters available by default, but still not as many as colorwrapper.

Now let’s see if I can find something that’s not a text colorization tool. …

colorex: I might as well include them all

This randomized revisitation of the C section has been a veritable tapdance through colorization tools. If I had known I had so many, I would have devoted a whole week to them.

I have one more that starts with C, and then I’ll return to the entire alphabet, as determined by shuf and ls. And since I’m on a roll with colorizing tools, I might as well finish up with colorex.

A lot of the “shortcomings” I mentioned in clog are resolved in colorex. For example, it will, as you can see, colorize specific chunks or strings of letters, for as many times as they appear on a line. It can also bounce between colors even when they are exactly adjacent.

And most of colorex’s syntax is at the command line, so you can declare a color as you build the filter command. It also adds a blink code, underlining effects and bolding … only some of which is visible in a virtual console, but you get the idea.

clog had a very straightforward configuration style, but colorex will require you to be a little more adept at the command line. Expect to escape some of your more complex searches and/or regexes to make sure colorex understands what you want.

As an added touch, colorex has a randomization command, which will either surprise you with its results or drive you batty with the spattered color effects.

Not since toilet has there been such a commanding use of color on my lowly X41. …

I should mention that the random effects only seem to work on a full line. And out of fairness, I should mention that colorex doesn’t have the same degree of control over color — like red on purple text — that you can get quite easily with clog. Perhaps that will be in future versions.

In spite of those shortcomings, I’m more inclined to adopt colorex than clog, just because it feels like there’s a stronger sense of control with the former than with the latter. It may not offer the same range of controls and it might be a little more challenging to configure, but it definitely picks up what clog stepped over.

clog: Custom color for logs

I seem to be awash of colorizing programs as I chip away at the C section. This is clog, which the home page describes as a colorized log tail utility.

That’s mostly true. It does colorize text and it does apply more to logs than straight text files. It lacks a feature or two that would make it a peer of tail.

Mostly, it lacks the ability to strain out the last lines of a log. By default, clog dumps everything to STDOUT, and ignores flags like -10 that are native to tail. A bit of a misnomer, then.

You have two options in your .clogrc file: either highlight an entire line, or highlight matching sequences of letters. (You can also suppress lines, which might be useful.) In that way you could use clog as a kind of stylized grep, and add a few more color options.

Some shortcomings: When you highlight a string of letters or a word, you will only see highlighting on the first occurrence. As far as I could tell, there was no way to highlight the same sequence multiple times in the same line. Several different colors on the same line will work, but only the first match for each color.

Furthermore, if you ask for full-line highlighting and the line matches more than one filter, you’ll only see one highlighting. I couldn’t make clog split highlighting. You can, however, highlight letter sequences overtop of line highlighting.

Those are shortcomings, but only if you’re trying to make clog behave like a strict color filter, and not a log colorizer. Think of clog like ccze, not like colout (or highlighter or pygments).

On the plus side, clog’s syntax for screening colors is terrifically simple. Step through the first three or four examples and you’ll have multicolor log displays in no time. And clog supplies date and time functions in case you want to stamp the output with either of those.

clog is a good tool, but not one I plan on adopting. I rarely peek at my logs anyway, and clog doesn’t handle enough grep-like colorizing to take over that role. If its abilities expand, I might consider it.

colour: Something to build on to

I’ll show you a snapshot of colour, and you can decide if you’re willing to build upon it.

colour is remarkably similar to colorwrapper, but will probably require a little more effort to bring up to the same level of flexibility. Both programs use profiles to filter program output and insert color.

But while colorwrapper (and rainbow for that matter) seems to have a few more profiles available to it, colour has only two that I see — and both of them are intended for nodetool, which I think is somehow related to Apache Cassandra. That’s waaay beyond my scope.

But colour comes with a couple of example files by default, so what you see in the screenshot is just those examples pumped through their respective profiles. I’m afraid I can’t show much more than that.

And since colour doesn’t seem to have any other configurations, I’m out of ways to use it. I know I should probably start making my own, but I’m short on time and only halfway interested in building up a collection of configurations for colour.

And probably you’ll be in the same boat. If you find colour promising, you’ll likely spend some time drafting your own configurations, for the programs you like and use.

It’s your decision — colorwrapper or rainbow, the more complete utilities … or colour, the underdog with potential. 😉

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?

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.

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

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.

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?

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? ❓

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