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! 😀 🙄

color-invaders.sh: A script! and a site!

My favorite e-mails are the ones with lots of exclamation points. It’s usually a sign that someone is quite enthusiastic about the program they want to share. Or quite incensed at something I wrote. 😦

karl sent an orchard of exclamation points (happy ones, that is) on Saturday along with a note about color-invaders.sh, which apparently has its roots on the Crunchbang forums.

And there you can see my very bland color scheme, which probably wouldn’t win any exclamation points from karl.

Aside from drawing the classic invaders in colors that you have set for your shell, color-invaders.sh doesn’t really do much. And there are lots of similar tools, that really only show what colors you set, so you can see if your desktop is something worth sharing with the wide, wide world. 😕

Part of karl’s enthusiasm though, was for a website that lets you experiment with colors and returns the codes necessary to implement them. karl didn’t say where that came from or if it was his own invention, but I don’t think it is.

I am sure there are other sites that similarly streamline the coding portion of custom shell colors; if there is a better one, feel free to mention it. And if you have a script or tool that displays shell colors in a more inventive fashion, pass it along too.

I am sure at least one person — mostly likely karl! — would be happy! to hear about them!

P.S.: For what it’s worth, I don’t usually run a custom color scheme, and that’s by choice. A long time ago I was looking at the colors in a program and wondering why some things were hard to see, and realized I had inadvertently mashed two similar colors together, making the program somewhat difficult to read. I keep it plain now. Sorry, karl. 😉

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.

pup: Playing fetch with HTML

Every month I export the posts from this site, grind away at the XML file, pluck out titles and links, and rearrange them to form an index page. Don’t say thank you; I do it for me as much as anyone else. I can’t remember everything I’ve covered in the past two years, and that index has saved me more than once.

Point being, it takes a small measure of grep, plus some rather tedious vim footwork to get everything arranged in the proper order and working.

You know what would be nice? If some tool could skim through that XML file, extract just the link and title fields, and prettify them to make my task a bit easier.

pup can do that.

Oh, that is so wonderful. … 🙄

In that very rudimentary example, pup took the file, the field I wanted, and sifted through for all the matching tags before dumping it into the index file.

pup will also colorize and format HTML for the sake of easy viewing, and the effect is again, oh-so wonderful.

That might remind you of tidyhtml, the savior of sloppy HTML coders everywhere, and you could conceivably use it that way. pup can do a lot more than that, though.

You can parse for multiple tags with pup, filter out specific IDs nestled in <span> tags, print from selected nodes and pluck out selectors. And a lot more that I don’t quite understand fully. 😳

It is possible that you could do some of what pup does with a crafty combination of things like sed or grep. Then again, pup seems confident in its HTML expertise, and the way it is designed is easy to figure out.

And for those of you who won’t deal with software more than a few months old, I can see that at the time of this writing, pup had been updated within the week. So it’s quite fresh. Try pup without fear of poisoning your system with year-old programs. 😉

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