checkmp3: Does exactly that

A long time ago I mentioned mp3check, and we also saw mpck and mp3val. checkmp3 does much the same thing as those tools, albeit with a little less … discussion.

checkmp3 adds on the oblique ability to “fix” mp3 files, by sending the entire file to STDOUT but omitting frames which appear invalid. I suppose that could technically “fix” an mp3 if you pipe it into another file, but I also suspect it would cause hiccups in some cases. The files I used for a test run were more or less intact, so I didn’t notice any difference in playback.

You see the Debian Squeeze version there (apparently it’s also in Sid), but the man page gives a Sourceforge address which is titled, oddly, MP3 Check. I tried building MP3 Check from scratch in Arch but ran into issues; all the same, I have no reason to believe that checkmp3 and MP3 Check are not the same program. (The mp3check we saw before was strikingly different.)

That’s about all I can think of to say. It’s a very straightforward tool and (apparently) does what it promises. Let’s move on.

sha* (with sha1pass and shasum): Sha-sha-sha

I mentioned md5sum a long, long time ago, and now I feel obligated to include the sha* suite. I think this might be where the free ride ends for checksum generators though. Here’s why:

That’s it, that’s basically all it does. Of course, it’s not like md5sum did much more. You can use this in much the same way as md5sum — checking file integrity where the publisher has a sum available to match, or as a fingerprinting utility where there was an intermediary in the transfer.

I wanted to point out that the sha* binaries are part of coreutils, but my Arch system has two other sha* programs: sha1pass, installed as part of syslinux, and shasum, which came with perl.

I can’t speak for either of those last programs, since I’m not sure what their original intent was. I have a feeling sha1pass works with passwords and encryption, while shasum appears to be a frontend for the sha* binaries. If you use sha* enough, shasum might be helpful.

But that’s why I said the gravy train might be pulling into the station for checksum generators: They have a very slim and specific function. And what I’ve seen of a few other checksum generators suggests that’s all they’re meant to do.

style: Similar idea, different direction

Both diction and style are components in the same GNU package, and that’s a little surprising since they obviously do quite different things.

I fed style the same passage as I did diction, but rather than pluck out problematic words or phrases, style gives a technical and statistical analysis of the text. So no specific grammatical warnings, aside from a tally of how many conjunctions I used — oops, I mean, the writer used. 🙄

However, unless you’re familiar with those tests, the scores listed there are unlikely to mean anything to you. I’ll give you this as a starting link, and from there you can explore on your own. Each test has its own metric, and it may be that just word structure or even number of syllables can swing results in one direction or another.

Actual computation aside, style works in a very fast, very clean manner and presents its results in a useful table. Options-wise, style has flags for specific grammatical structures or voices, plus some triggers for sentence length or certain test results. If you want to screen out sentences more than 20 words long, for example, style is your tool.

So again, style is not so much a grammar checker as it is a writing analyzer, with the added ability to pop out lines that meet certain criteria. Kind of a like a grammar-grep, I guess.

I can’t necessarily endorse either diction or style as must-have tools if you do a lot of writing at the console, or even if you just do a lot of writing. They’re helpful, but might seem primitive compared with some conventional, contemporary applications. Keep them in mind though.

In the mean time, send me a link when you finish your text-based user interface grammar checker utility. The world awaits the arrival of your genius. 😉

diction: The words you choose and why

Earlier this month I pointed out a grammar checker utility that was, because of its age and its arrangement, omitted from this daily showcase of software. And I felt a little bad about that because as far as I can tell, it was the only grammar checker for a text-only environment that I’ve seen in 21 months.

There are two conclusions to be drawn from that: One, that relying on outside sources as a core component of your software might make it obsolete before its time. And two, if you’re a budding programmer looking to make your mark on the world, there’s a big open gap right around text-based grammar checkers.

If you want to take a step in that direction, take a gander at diction.

In that example, I fed diction a short and cumbersome passage from some lunkhead-Linux-blogger-wannabe I found on the Internet. 😉 And if you look close, you can see where diction plucks out particular words and phrases, and gives you reminders — sometimes grammatical — on usage.

Not really a grammar checker, and not really a dictionary, which makes diction something in-between.

Points of note: diction is really just a filter for specific words and phrases, with cued responses inserted where appropriate. That’s important to remember, since rearranging or misspelling those key phrases is going to let diction pass right over them.

Furthermore, diction is hopeless at innuendo, double-entendre, turns of phrase or deliberate wordplay. If it’s not in the onboard repertoire, diction will either run right past it or flag it as some sort of unrelated error. So higher-order writing is susceptible to false positives.

The only other gripe I have is that the output is particularly dense. No color filtering, no line-by-line trapping, no formatting aside from the use of square brackets to set off comments from original text. So while I appreciate the effort diction goes through, the results are going to need some heavy adjustment before they will be readable.

All that being said, this is a step in the right direction for anyone who wants to do some text wrangling from the command line. diction sends its analysis straight back through STDOUT, so it’s a simple matter to pipe it into something else — like one of the million color filtering tools we’ve seen — and further adjust it.

Now let’s move to diction’s little brother. …

linkchecker: Relax your mouse clicker finger

I seem to be on an Internet-based kick these days. It started yesterday with httpry and html-xml-utils; now I’m on to linkchecker, which cascades through pages or sites and checks that the links are … linking.

linkchecker came at a good time, since I got an e-mail a week or so ago, mentioning (not really complaining, just mentioning) that most of the software I touch on seems to have been around for quite a while. The suggestion was, “When are you going to show us some fresh stuff?”

Well, linkchecker has updates within the past few days, and I’d bet wummel is working on it even as you’re reading this. How’s that for fresh? 😈

What linkchecker does and how is probably obvious just from the name, without looking at the screenshot. And of course, you should probably be careful where you aim linkchecker, because as you can see, it had stacked up several thousand links to check within only a minute or two of looking at this page.

Perhaps it would be better kept in-house first, before turning it loose in the wild. 😐

linkchecker has a long, long list of options for you to look over, in case you want to check external URLs (gasp!), use customized configuration files or filter out URLs by regex. Or a lot of other things.

Perhaps the greatest part about using linkchecker though, is that it allows you to relax your mouse clicker finger, and do other things. Interns everywhere will rejoice. 😉

And just for the record, without any snarky undertones, I do have a tendency to pull in a lot of old, or outdated software. If it still works, I’m still willing to use it. I hope you feel the same. 😕

hunspell: A spellchecker with vast dictionary support

I see an occasional spellchecker around here — there was aspell and ispell a long while back, look was another one. codespell was good for picking through code for spelling errors, and I guess in an offhand way, dict is a spellchecker. Here’s a great one for stepping through a document and picking out errors: hunspell.

hunspell was already installed on my Arch system, as a dependency to a dependency to a dependency to Pidgin. I see that it’s also optional for a lot of other programs, like Pale Moon or even re-alpine. Which I suppose, is a testament to its usefulness.

In its console interface, hunspell shows the possible error in context, alongside a list of suggested replacements. Key in the number of your correction, or use one of the other options to replace or ignore the error. Reach the end of the document, and you have the option to save. Easy as that.

It’s very sparse, but then again, it’s a tried-and-tested formula. Text-based spellcheckers have been around since the 1970s, if not earlier. We’re working with the benefit of experience here. … 😉

Besides the obvious “no color” complaint, I can’t find anything that is a detriment to hunspell. Like I said, my Arch installation had hunspell installed already, but I needed to install the English dictionary before it would work directly on a text file.

And that might be part of hunspell’s greatest asset: An immense number of dictionaries. I doubt that list is complete; add to that the number of LibreOffice and Mozilla extensions that the home page implies. Plus MySpell dictionaries. And Android and Abiword support.

I’m drifting off-target again though. My real desire here was to show you the terminal interface, and point out that it’s a very real possibility that you’ve already got it on your system. Install a dictionary, and hunspell is ready to roll.

Now I had better go over this post one more time, to make sure I didn’t commit any errors in here. … 😐

codespell: Prevents embarrassing code

Today is Pick on Kernel Developers’ Spelling Abilities Day.

As if they didn’t have enough work to do, along comes me and codespell to harass them about their spelling mistakes.

Spelling is sometimes important though, so a spellchecker specific to code is probably a good idea. And since I have no ability when it comes to creating software, I have to have something to complain about.

codespell is neat stuff, and I don’t say that just because it has a lot of color in it. For one thing, you can step through a folder of code word-by-word, and codespell will give you the chance to correct things interactively.

Aside from that, codespell can write corrections directly into files, print a summary of the changes it suggested, and access custom dictionaries. There are quite a few other options, include one to — gasp! — strip out all that lovely color.

As I understand it, codespell’s main reference is part of the release, but is derived from Wikipedia’s page of common misspellings for machines (and-or technology).

If you really want to put codespell through its paces, I would suggest matching it head-to-head against something like aspell (or ispell or …). The difficulty in that, of course, is that aspell (or ispell or …) is likely to stumble over any portion of code that doesn’t look like a standard English (or other language) word. Which means codespell might end up saving you time.

And now for my regularly scheduled pity party, where I insist I would make much more use of codespell if I had a stick of programming ability. I’ll spare you that this time; if I had spent a tenth of the time learning to write software as I have moaning about my inability, I’d have come up with something vaguely usable by now. 🙄

shellcheck: I should probably keep this around

I have all the programming ability of a wet dog. I am aware of that shortcoming though, and I try to keep things on hand that either (a) make me look like I know what I’m doing, or (b) will discreetly tell me when I don’t know what I’m doing, so as not to embarrass me in front of the hired help.

Hence my affinity for things like perltidy, tidyhtml and even txt2regex. 😛

Even if I don’t keep shellcheck installed, I’m keeping a bookmark to its online version, because it definitely lets me know when I’ve done something stupid.

That’s my goal in life: to stop doing stupid things. And shellcheck has already told me that I’m doing one or two in that script.

Things I like: the colored output, the arrow-pointers to tell me exactly where I made my mistake, and the error codes that I can use to get more information online. And by extension, the ability to exclude specific errors, if I know they are in there but don’t want to be teased about them.

Things I would suggest: It’s a little difficult to take some errors out of context, particularly if they break over a line or if something earlier in the script is related. As things stand, shellcheck only seems to point out lines that have errors, regardless of where they stand in relation to lines above or below.

As a side note, it seems like this is an obvious candidate for some kind of two-pane output display, with the text of the shell on one side, and an arrow-key-driven selector that bounces between errors, with the error code and explanation changing in a second panel, as the highlight moves. Imagine how some file managers show file information as you scroll through the contents of a directory, and that’s what I have in my mind.

But what do I know. Maybe I’m just dreaming, and what shellcheck has is good, but that’s what I’d look for in an updated version.

shellcheck in its local form is a bit of a heavyweight, when it comes time to build it. I usually have rotten luck with Haskell-based software, but this time the AUR package worked fine. The home page warns that you’ll need about 1Gb just to build shellcheck, and I think that’s where my machine peaked while it was building. So don’t put this together on your leftover 300Mhz K6 with 128Mb. You will regret it. 😦

mpck: Seemingly misnamed

So long as we’re on mp3 file checkers, mpck is available too.

Had it been me, I would have named it mp3ck, but that is neither here nor there.

In the same sort of fashion as mp3check and mp3val, mpck skims mp3 files and checks for errors.

And again, without a damaged file I don’t know what I can show except happy results.

mpck does have a couple of unusual flairs though: It will check for names that are longer than a certain limit, check for “strange” characters, and check files with extensions other than just mp3.

I see no option to fix files though, so it may be that you need another tool for a monkey wrench, if mpck throws errors.

And this time the tables are turned: mpck is in Arch, but not Debian! Revenge! 😉

mp3val: A simple validation check

I’m coming to grips with the fact that my Thursdays are more or less overloaded, and if I want to keep up my two-a-day pace I’m going to have to make preparations.

Fair enough. Here’s one I anticipated yesterday: mp3val.

Much like mp3check from last week, mp3val runs through the files you give it, and checks over the guts.

mp3val has the options to fix errors, preserve timestamps, keep an error log, etc. It seems quite prepared to do a thorough job.

I say “seems” again because I went through the mp3 files I have and didn’t get any errors, like you see in the screenshot.

mp3check though, marked those with small inconsistencies, which now makes me wonder if one or both of these programs is slightly out of whack. One is giving warnings, the other says remain calm, all is well.

Perhaps if I had a file I knew to be damaged, I could troubleshoot one or both. If you have an mp3 that is corrupted, maybe you can perform due diligence. I have a few more posts to get through this morning. … 🙄

By the way, this is another that is in Debian &c., but not in Arch. 😯 Blasphemy! 😉