Tag Archives: color

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. πŸ˜‰

colorwrapper: Quite obviously, the author had me in mind

Boring. Dull. Uninteresting.

2014-07-17-6m47421-date-pstree 2014-07-17-6m47421-netstat

Exciting! Interesting! Readable!

2014-07-17-6m47421-colorwrapper-01 2014-07-17-6m47421-colorwrapper-02

I get razzed occasionally about my preference for color in … well, in just about anything that passes through the console. I must not be the only one, for as many colorize tools as there are.

colorwrapper — instead of screening program output for colorizable (is that a word?) strings, or requiring you to select a color scheme from a list — uses an executable preset profile to catch and colorize the results of a command. (I’m avoiding the word “wrapper” here, just for clarity.)

I don’t know how to explain that properly. But here’s a snippet from the profile that produced the colorized version of pstree, above.

path /bin:/usr/bin:/sbin:/usr/sbin:
ifnarg -G:-U
base cyan
digit green+:default
match white:default |
match white:default )
match white:default init

I trimmed away a little bit for the sake of space. But I think you get the idea — the profile tells colorwrapper what to pluck out, and where the colors appear.

By default, colorwrapper comes with a huge list of profiles for commonplace Unix-y commands, and if you take a little time you should be able to either edit those to your particular color scheme, or to produce some of your own. For what I’ve seen of colorwrapper, the markdown is fairly intuitive.

This is something we’ve seen before, in programs like rainbow. Compare what rainbow does with ping, to what colorwrapper does:


Not everything is green and cyan with colorwrapper, by the way. It depends on the tool and the profile. πŸ˜‰

A few caveats, because there always are some: colorwrapper is pushing toward five years without an apparent update; I mention that out of a sense of obligation and because I know there are some folks who won’t touch a program older than a few weeks, regardless of how well it works. Whatever. ❓

That does suggest though that some profiles (I didn’t check them all) might not be current with what the tool can do. The author talks about colorizing top, for example, and as we all know, top has its own built-in color scheme system. We all know that, right? RIGHT?! πŸ‘Ώ

Second, I am sure you noticed that there was a slight difference between the output of straight pstree and colorwrapper’s version of pstree. You might want to step through the profiles you like best, to make sure the output you prefer is what appears with colorwrapper.

Also, if you want to give colorwrapper a test run before committing, notice that the make command has an option for localinstall which will drop everything into $HOME/.cw … which makes it easier to get rid of, when you realize K.Mandla is stark raving mad. πŸ™„

I’ll leave the rest for you to discover. The home page for colorwrapper is particularly sparse, but the bundled documentation is quite good. Watch for headers and footers too, which throw an added color element into the equation. Have fun! πŸ™‚