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.

 

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

qrq: How little I really know

I found qrq by way of a brute search through the Debian archives for anything text-related, and even though I haven’t a clue what to do with qrq, I’ll show it here out of fairness.

 

That’s only partly true — I do have a small idea what to do with qrq. The home page is very helpful, and the program itself has more than enough help just in its startup screen to keep me from shrugging with complete bewilderment. And I imagine if you’re learning or use Morse telegraphy at all, it will be very interesting.

It’s also worth highlighting that qrq involves some sound support. Very few console applications take the time to incorporate an audio element, unless they’re specifically intended for audio playback.

At this point I should mention that I have no training whatsoever with Morse code aside from learning about it in primary school. Or maybe tinkering with morse. So properly using qrq is well beyond my ability.

On the other hand, I do like the interface, even if it is pinned to 80×24. qrq has no flags that I could find, and the man page gives only a little more information than you’ll get from starting the program.

I noticed that qrq is in both Debian and Arch, and the Arch version will pull in alsa-oss when you install it. That might suggest that qrq is a little beyond the most recent developments in Linux audio, but I had no problems with qrq’s sound playback.

Other than the fact that I have no clue what those beeps and boops mean.

Between this and yfklog, I’m beginning to expect more from text-only applications intended for the amateur radio demographic. … 😐

gist: So long as I am eating crow. …

I might as well go ahead and get a second helping of humility. After royally fumbling klick, I need a second smack in the head to acknowledge my error with gist.

Yes, I’m afraid I can’t just pretend I didn’t flub this one too.

My mistake was confusing this for another pastebin-style uploader, and discounting it on the grounds that the other one required an account signup. Sorry. After 1100 posts and ~1500 software titles, it gets hard to keep track. I should have a list or an index online somewhere. … 🙄

The real tragedy is, when compared to other pastebin tools I’ve seen in the past two years — like elmer or uppity or some others — gist is one of the better ones.

Some of gist’s cooler functions that I’ve noticed: automatic URL shortening through git.io, direct hookups with both xclip and xsel, updating existing gists with just the address hash, and one-time account authorization with the --login flag. Nifty.

One thing I’ve seen other tools do that I don’t see offhand in gist: Access to several different hosts. But I suppose that’s the nature of the tool, and what’s available through Github Gist.

At this point, with the landscape of pastebin tools largely dependent on what site they can access, I imagine the choice of tools might shift to what services the target site offers. For that reason it might make sense that gist wins fans among programmers.

Just from the upload page you see in the screenshot, you can fork an uploaded snippet, watch revisions and clone it off the page. I can see the appeal among coders; someone’s random list of words quickly becomes the next killer app.

So hopefully now I’ve done my penance for both klick and gist, and made up for one mistake and one misunderstanding. 😐

ngp: Find it and edit it, in one deft motion

These days I seem to be finding less and less tools that really grab me, and more and more that seem to fall short of the mark somehow. ngp is one of the former, and this one I think I shall keep around.

ngp is like a recursive, colorized, interactive grep. If you take the output of ack, make it navigable with a selection bar, then add the ability to jump straight into a selected file with your $EDITOR, you’ll have an idea of what ngp does.

So for example, this

 ngp -r ion

Takes me straight to this:

And from there, if I highlight a line and press enter, I jump into $EDITOR and can adjust as necessary. Leave the editor and ngp reclaims the terminal, showing the same results but with red text, so I know I already traveled there. Very smooth. 😎

ngp strikes me as a tool someone would invent where they see themselves repeating the same task over and over, and relying on two or three terminal windows to track their progress. And if you work in text files a lot, or through trees of code, I imagine ngp would save you some time finding certain problems, and fixing them.

ngp can be a little finicky, so watch your flags carefully. And I might have compared it to grep but it’s not feature-compatible, so don’t start throwing wild strings of flags at it and expecting it to munch them down the same way grep does.

But for a find-and-replace or find-and-edit or search-and-destroy at the console tool, ngp has everything tied up in one, nice, neat package. A well-earned, albeit completely valueless, K.Mandla gold star: ⭐ Enjoy! 😉