sdcv: Local lookup, some assembly required

I’m a big fan of dict, the online dictionary and thesaurus tool that runs almost completely at the command prompt.

Of course, if I’m stuck offline, I’m stuck completely. Words fail me. Literally. :shock:

sdcv is a console interface to the somewhat-dated StarDict tool. And in contrast to dict, sdcv works with locally downloaded (or created, I suppose) dictionaries.

2014-04-19-6m47421-sdcv

There’s not a whole lot to see with sdcv, although that will depend entirely on how many dictionaries you have, and what you ask of them.

Output is a little odd. I think that might be because the dictionaries are intended for a graphical tool, not strict text.

I don’t see any options within sdcv to strip out that coding, so I’m going to enlist the services of dehtml … and that’s what you see above. It’s not perfect, but it’s more readable than as it appears raw.

Of course, the alternative to that is to pipe sdcv’s output into a file, and use a browser to open it.

2014-04-19-6m47421-sdcv-elinks

Either way, there may be some added steps to viewing a definition.

On the other hand, you do have the pick of several dictionaries, cross-language or otherwise, and they’re stored locally. And being the clever young hacker that you are, I’m sure you’ll find a way to build your own dictionaries too.

So to recap … dict for online dictionary access in clean plain text, or sdcv for custom dictionaries stored locally and subject to your scrutiny. You can choose which you like. Or … why not both? :mrgreen:

scrollz: Fast, friendly and light

The man page for scrollz told me a lot more about it than I had written in my notes.

2014-04-19-j05sdg1-scrollz

A lot more than was on the home page either, although to be fair, there seem to be some domain redirection issues there. :|

scrollz is written in C, and I’m a fan of most any program that can trace its heritage back to C … mostly because they seem to run faster and lighter than most other software. You can see that in things like cmus, mcplay, ctorrent and some others.

scrollz also boasts that it carries a lot of the features seen in IRC scripts as part of its internal structure. I am afraid I’m not enough of an IRC fan to know what those scripts are, or why they’re so great.

The features also include Blowfish encryption — which I can see the reason for — special features for IRC operators, user-friendly nick and channel completion, and some other things.

The user-friendly completion sticks out in my mind, after years of working with irssi and after only recently jumping ship to rhapsody. It’s nice to have an application prompt you for your nickname rather than just spit demeaning errors at you, and expect you to know how to fix the situation.

Egads, am I shifting back to the graphical side? :shock:

Not likely. But it does mean that scrollz — kind of in the same way as rhapsody, but to a lesser degree — seems to have a less staid approach.

And I will mention that I like the status bar that scrollz employs. That, on top of a gilded tmux or screen status line would be another geek trophy.

For the moment I’m still enraptured by rhapsody, and my efforts to build scrollz in Arch were less-than-fruitful (it says I “must get working getaddrinfo()” … whatever that means). I will keep it in mind though, for future adventures

screen: The granddaddy of terminal multiplexers

I was for a very long time a faithful user of GNU screen.

2010-06-26-fmv-5120-vtclock

That has mellowed somewhat over the past few years, partly because tmux — I must admit — is leaps and bounds beyond what screen can do, but also just because there are other options too.

Things like dvtm, or even twin, which both handle the concept of multiple-terminals-one-screen in their own fashion.

Any of those three can do … somewhat something similar to what screen does, and have probably all seen more improvements over the years than screen.

I hold no one responsible for screen’s slow spiral into staleness; in fact, if anything, that makes screen quite easy to figure out: There is plenty of discussion about screen and how it works … even if some of it isn’t flattering. :shock:

It may be the ugly stepmother of terminal multiplexers, but you can’t deny that it does what it claims. And in the realm of console-based software, that alone is sometimes enough to get by. In my book, anyway. :roll:

screenify: A tetchy little tool

I have screenify on my list, and I think it’s a little out-of-order to speak of it before recapping screen proper. And since screenify strikes me as a little less than practical, I’ll just skim through it. There isn’t much to show anyway.

screenify should do much like what reptyr does — yank a running process into another terminal, but I haven’t met with much success.

Documentation is very scant for screenify. I got it to work once, basically following the crude steps in this zsh mailing list reply, but it hasn’t worked since then.

If I understand properly, these are the steps:

  1. Start your process in one terminal.
  2. Use CTRL+Z to pause it.
  3. Then disown the process, which should free your terminal and if you’re lucky, show the PID of the free-spinning process. If not, check top or another tool.
  4. Now from within screen, use screenify PID and you’ll get some rambling text along with a confirmation.
  5. From yet another shell, issue kill -CONT PID, which should redirect the output into your screen session.

Like I said, it worked for me once, but never again. Just dumb luck, I guess.

And processes other than very simple, single-PID, non-console-applications don’t seem to follow through. In other words, bc, htop and alpine all refused to jump between terminals for me.

So I’m not sure what I did. It might be that it works better for you than me, but it will rely on screen in the first place (which I know is not the favorite terminal multiplexer these days) and gdb … at least it did for the Arch version. :roll:

If you get it working or can explain it better, please share. I have a feeling this is another one of those things that will do its job correctly under specific circumstances, and I don’t want to sell it short. :???:

scapy: If you can’t dazzle them with brilliance

The thing I like most about scapy is that it makes me look terrifically geeky-smart.

2014-04-18-j05sdg1-scapy

That’s the Linux Mint version, and … I haven’t a single clue as to what it’s doing. I was just following the commands on the demo page.

I see on the home page that scapy is intended for packet manipulation. And I see that it’s interactive and multicolored, and for that I award points.

But what it’s doing is far beyond anything I can imagine, as a lowly desktop user.

However, I know full well that there are very talented people out there beyond my computer screen, and it may be that scapy is something incredibly useful and interesting to them.

So if you’re into packet manipulation, either as part of your job or just for the adrenalin rush, scapy is there for you.

And if you’re in the movie industry, the next time you need something generic to dump into your film that looks really geeky but is more than likely harmless … scapy might do the trick. :roll:

scanlogd: Nothing to see here

I’m a little behind the power curve today, after spending the day with some curious computer issues, which may or may not be related to hardware upgrades.

Also a curious issue: scanlogd. The curious part being, I am afraid I don’t have anything to show for it.

kmandla@j05sdg1 ~ $ sudo scanlogd
kmandla@j05sdg1 ~ $ 

If something beyond that is supposed to happen, I can’t see how it comes about.

I’ve been working with the Debian version, which installs and starts without issue, but doesn’t … really … seem to show anything for the (miniscule) effort involved.

I read through the man page, and maybe that lack of output is OK. It seems it shouldn’t really do anything unless someone attempts to scan ports on that machine — in which case it should just make a note of the attempt somewhere in /var/log.

Which is very very unlikely to happen, given that scanlogd is just wallowing around on my home network.

I will leave it to the more knowledgeable server managers to see if it is of any use. As for me, as a lowly desktop user, this doesn’t seem to have a function. :(

scalpel: File extraction and recovery

I am a newcomer to scalpel, so I didn’t know what a “file carver” was when I started it. But now I like its style.

2014-04-17-6m47421-scalpel

I’m using an old floppy image from a couple of years ago, and asking scalpel to pluck out any files it finds that match certain types.

What you can’t see there is the configuration file, which is where most of your control over scalpel will reside.

If you’re looking for specific types or file extensions, you uncomment them in the conf file and scalpel will include them in its search.

In my case, this avoids the need to write out that image to a floppy, mount it, and go digging for the file manually. Oh, so tiresome. :roll:

Of course you don’t have to use scalpel on images, just a /dev/sdXY location should work as well.

scalpel is in both Arch and Debian; the AUR version yields a 404 though. Look at the comments on that page to get an archived link to the source file.