Tag Archives: code

ascii: Quick and dirty info

This next title is a quick and obvious tool, and I had been holding it back because it seemed a little too simple. This is ascii.


Which, as you can see, either displays a chart of ASCII conversion data, or takes a string of digits and returns their conversion, as would be useful in a script. Escaped characters and control characters are possible too, as well as octal or hex values.

ascii does a few other things that serve in the same kind of situation; check the help flag or the man page for ascii’s second-string tricks.

But … that’s all I can think to do with it. The value in ascii is its quick-fire accessibility to character codes. And beyond that … ? :\

unhtml: Peeling away the layers

Last week I ran across three gold-star-winner programs in a matter of days; this week I seem to have run aground on one-shot command-line tools, clients or application frameworks.

No matter. It takes all kinds. Here’s unhtml, and you can probably guess as to its goal.


unhtml is one of probably two or three (or four or five …) html-strippers that I’ve seen since the start of this silly little site, and while it’s not the most elegant or flexible, it might be the oldest.

The man page for unhtml has a date of 1998, and if that’s its inception date, then it has done well to survive this long.

Of course, it probably has Debian to thank for that — I looked briefly for an original home page, but didn’t find anything that satisfied me. And considering that the AUR page for unhtml simply pulls the source code from Debian, it might be that it’s only around now because of the way Debian preserves code.

I can’t speak very highly of unhtml no matter its age; its only flag is a call for the version, and even the man page is exceedingly terse. You have the flexibility to pipe code through unhtml or to aim it at a file, but that’s about it.

All the same, I think it does the job, and with the exception of a few oddball tags like you see above, it did what it promised. Given the option, I might rely on something else though. Personally, that is. :\

wiggle: A little room for wiggle

I have wiggle on my list for this morning, but I don’t know if I can show a very useful case for it.


I understand from the program description that wiggle is designed to patch code where patch itself can’t, because of conflicting changes or some other error.

Personally I couldn’t come up with something so intricate to show what patch couldn’t do, but wiggle could. It’s another one of those situations where I’m trying to find a broken case for a program, so I can demonstrate another program. :\

Which isn’t very easy if you’re not one of the people who immediately sees the use of wiggle anyway. I’m guessing if you read through the description of wiggle and say to yourself, “Hmm, that could be useful to me. …” then you’re already way ahead of me.

So I’ll leave it at that. I should mention that wiggle is in Debian and AUR; both wiggle and wiggle-git stopped on warnings for me, so you might want to disable warnings that are treated as errors when you build it.

Of course, the Debian version runs fine. There’s the convenience of a precompiled distro. Then again, the Debian package page links to a dead home page, so there’s the convenience of AUR, too. … πŸ˜‰

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.

2015-01-15-6m47421-icdiff-01 2015-01-15-6m47421-icdiff-02

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.

morsegen and morse2ascii: Since we’re on the subject

I have a couple of other small Morse telegraphy tools in my list, and since we covered cwcp in the last post, it’s probably a good time to throw them into the mix. Here’s morsegen, from Luigi Auriemma.


As you can see, morsegen is very straightforward, and really only reads text files and converts the contents into dash-or-dot sequences. No flags or frills, unless you consider the readout of Luigi’s fixed header to be a frill.

In that sense, I would prefer morsegen work a little more like morse, and accept text either as a target, or through a pipe. morsegen seems hard-coded to look for a target file, and read through that.

Which is all neither here nor there, and perhaps if you like, you can ask Luigi’s permission to adjust morsegen. I wonder if that wouldn’t make morsegen nearly identical to morse, though.

Here’s something a little more ambitious, by the same author: morse2ascii.


The inner workings of morse2ascii are beyond me, but suffice to say that it reads through a wav file, senses the tones, and converts them into text. You can see the analysis and the results in the screenshot, taken from a random sound file borrowed from The Internet. πŸ˜•

As far as I can tell, as someone unskilled in the art of decoding Morse telegraphy, morse2ascii is doing a good job. The file I borrowed was supposedly a training session, working through basic letters and digits before moving into specific sequences. It looks right, anyway.

morse2ascii has the same arrangement as morsegen though, and won’t accept strings and wants a target file. So if you want to stream audio through morse2ascii, you might need to first capture the broadcast, then feed it to morse2ascii. I leave it to you to solve.

Both programs compile and run fine in Arch; morse2ascii is in AUR if you prefer. Debian has both prepackaged. Debian users get all the cool toys. … πŸ˜‰

cwcp: Learn to walk before you run

I found qrq a week or two ago, and while qrq is probably a very useful program for people who need to improve their skills with Morse telegraphy, it might be geared more towards those who have already mastered the basics.

If you’re a newbie, cwcp might be more to your liking. Here’s the Linux Mint version.


Much is the same between qrq and cwcp, but it’s also clear that their target audiences are different. cwcp has speed and volume controls, but also has controls for adjusting tone and other audio cues.

qrq seemed to focus on recognizing call signs and building proficiency and speed, while cwcp starts with letter and number groups, and works up through English words and into other categories. cwcp also lets you type in your own text, and will replay it as tones.

Like qrq, cwcp will need a little nudge with the alsa-oss package. I don’t see where that’s listed as a dependency in Debian, but I don’t know that oss is necessarily out of fashion, particularly among Debian fans.

In any case, if you’re not hearing anything, that might be the reason. cwcp is part of the unixcw package, so it might be that you get more “modern” sounds support by bringing in the qt rendition. Try it and tell me.

cwcp alone is not in Arch, but the unixcw suite is in AUR. If you only want the one program, it may be possible to carve it out. And if you’re an Arch user you probably can handle that. 😎

cwcp has color, as you can see, and I should note that cwcp seems comfortable arranging its layout to just about any terminal size, but only on startup. If you change dimensions after you begin your tutorial, cwcp might not notice it.

I think that’s about all I can think of to say about cwcp. It’s definitely every bit as fucntional as qrq, but intended more as a learning activity than as a speed and proficiency drill. Enjoy. πŸ˜‰

cscope: The code navigator

Short post this time, since I have almost no frame of reference for cscope. I have all the coding ability of a day-old banana peel, so a tool that searches, arranges and navigates source code files is far and beyond me.


That’s cscope picking through the source code for curl, which was just an arbitrary choice. Nothing to be inferred in that.

It’s a very smooth tool though, and if you spend any time at all navigating large files or skimming through trees of code, I can see where cscope would be a huge asset.

From my very cursory inspection, you can set search strings or patterns through the prompts at the bottom of the screen. Matching lines will appear in the top half, and you can use the arrow keys to pick through them. Press enter, and cscope opens your $EDITOR for you to make changes.

Help is available at the ? key, and you can exit with CTRL+D. Just so you know. …

I know very little about coding, even less about cscope, and have only a brushing knowledge of some of the search tools aimed at developers — programs like ag or ack. I can see where cscope might be preferable though, since it offers an interface to your activity.

But of course, you are the best judge of that. πŸ˜‰