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.

vbindiff: Red and blue

Is it time for a hex editor? It’s time for a hex editor … of sorts.

I have to admit a small amount of surprise in seeing a program as venerable yet well-maintained as vbindiff that seems to have skipped a few small steps in its presentation.

Going by the home page, the first “release” of vbindiff was for the OS/2, way back in 1996. Through the years it appears to have shifted more towards the Windows environment, but added *nix support less than 10 years ago, and for what it’s worth, is packaged in both Arch and Debian.

And my fleeting interactions with vbindiff suggest it is a workable, usable program at the very least. It wisely uses a horizontal split-screen arrangement and a strong white-on-blue backdrop, and keeps almost all its key commands on the screen, when they are relevant.

You can edit a file as well, making it a practical hex editor as well as diff tool. It’s not as graceful or elegant as some, and not nearly as splashy as others, but it fills both needs without tripping up.

Except for two or three small things, and this is where my surprise comes in. First, as you can see in the screenshots, vbindiff is apparently comfortable stretching to a depth of at least 42 lines, and possibly a lot more. That I can guess from my terminal depth.

But I don’t see a flag or any option that will stretch it horizontally, which means that there’s a huge, huge gap of wasted space off to the right. Yes, I know 120×42 is unconventional, and I respect that 80×24 is the standard that reaches back to the 1980s. But it’s a bit of an omission — a giant glaring omission, really — given the tiling window manager trend, and the prevalence of terminal emulators.

Second, vbindiff is slanted toward picking out differences between files, but there’s no visual indicator — and by that, I mean color difference or even just a difference in bolding — to highlight changes. Perhaps that’s intentional, or perhaps there’s a way to set that in a configuration file, but I see no note of it in the man page or onboard help.

Add to that the use of red on blue, which would horrify my secondary school art teacher for the shimmering side effect it has for most viewers. I forget the name of that effect or I’d link to it, but it’s not that critical. White on blue is very good, but red on blue is going to offend Miss Crawley, wherever she is now. Maybe she is responsible for my preference for color at the console. … 😐

I should mention that by its own admission, vbindiff can’t handle files greater than 4Gb in size. Of course, if you really need a diff tool for files that are bigger than 4Gb, then I think you have bigger problems than just color choice.

vbindiff does a few things I like — the aforementioned on-screen help is always good, and it allows navigation with arrow keys. It also uses the Enter key as a quick jump to the next difference between files, which will make some of your diff quests easier.

But I don’t think this stands up to things like dhex or some others. It has potential, but really needs to be brought up to date.

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

tig: The dream application

I have to give high marks to tig, a text-mode interface for git, even if I may never, ever, in this life or the next, have the chance to really put it to use.

 

That’s just lovely. Color everywhere. Line-drawn characters showing connections between revisions. Breakout panels for examining code in detail. Line-by-line color coordination for easy viewing. Intuitive controls. Left-and-right panning, as well as scrolling. Onboard help screens. One-key jump to $EDITOR. The list goes on.

tig is like my dream application. It’s as if someone read through every post I’d made for the past eight years and distilled it into one program.

And the irony is, I will probably never get to the point where I could use it. 😦

No matter. This is definitely worthy of a coveted K.Mandla gold star: ⭐ Enjoy. 😉

patch: Piecing together what I should say

I’m a little timid about mentioning patch, mostly because I have a feeling that there are literally thousands of people who know patch a lot better than me.

I’ll spare you the action-packed screenshot this time, since I can’t really patch anything without both target code and a viable patch to use.

My earliest run-ins with patch, aside from blind and wild swings while using Ubuntu, were while tinkering with Crux ports, years ago.

These days I occasionally have to fine-tune an errant PKGBUILD with patch, but that’s the exception and not the rule.

So my experience with patch is very superficial and I won’t embarrass myself by throwing out random suggestions. Especially when I am sure there are many verified experts hovering on the fringe, ready to answer questions.

patch is obliquely related to diff, which we looked over a long time ago. In Arch though, patch lives in its own package (named patch, as you might expect 🙄 ). In Debian? Wouldn’t you know it, patch is in patch.

Which I suppose means you could have one installed on your system, but not the other. Why you would want that is beyond me. 😐

So now that I’ve told you basically nothing about a tool that’s just about everywhere at once, I’ll shut up. If you can’t say something nice — or in this case, smart — don’t say anything at all. 😳

mcdiff, mcedit mcview: Internal tools, externalized

I can’t mention mc without pointing out that at least three of its internal tools — a diff’er, an editor and a viewer — are accessible without actually starting mc straightaway.

  

Left to right, mcdiff, mcedit and mcview. McThankYou. 🙄

As far as I can tell, these are mirror images of what you get when you cue the tools from within mc. And as you can see, they all follow mc’s general look and feel.

I am not a huge fan of any of those sub-programs, but I will admit I use the viewer frequently, if I’m already in Midnight Commander.

For most other uses, I rely on vim, diff and most, depending.

Point being, if you become accustomed to mc’s style and arrangement, and you don’t ally yourself with any particular viewer or editor, these three might save you a little disk space … and spare you learning another whole program. 😐

diffh: Make your diff easier to see

This one is similar to dailystrips, in that it generates an HTML page as its main output. But this time, it’s working in tandem with diff, to make things a little easier on the eyes.

Definitely a picture is worth a thousand words here.

Not that there’s a lot to point out there, but with the -u flag in diff, piped through diffh, you can come up with a visually clear representation of what diff is trying to tell you.

I’m not a programmer so maybe there are better, more obvious ways to show diff visually, but I can see where a couple of large files would be easier to understand this way.

And that’s all I can think of to say. 😐