Puzzled by screen’s stuff

One little problem I’ve been trying to decipher for my own benefit is a script to shut down screen. I usually have five or six applications running in screen, and when I close the machine for shutdown, I manually step through each program, giving it the command to close (and sometimes save).

Since it’s possible to pipe keystrokes through screen to the appropriate application, it seems to follow that a simple five- or six-line series of commands could cleanly save and close everything I usually have running. Technically, the command looks like this:

screen -p elinks -X stuff Q

A shifted Q is a quick shutdown command for elinks, and sending that through screen to the window entitled “elinks” (which is always called “elinks,” because it’s triggered at startup in my .screenrc) causes the application to stop. This will shut down alpine, since the command there is a q, followed by a y to answer yes to the confirmation.

screen -p alpine -X stuff qy

And so forth and so on. htop can close with a q, wyrd with a shifted Q. The problem comes with applications that require function keys as shutdown commands, such as mc‘s F10 close command, or a series of Escape keys for centerim, or hnb which wants a CTRL+Q to quit.

For some reason, using the keystroke sequences in the GNU/Screen user’s manual don’t enter as escaped, instead they spill onto the screen as typed characters, or are ignored since they don’t form an escape sequence. So if I try this, which I think sends an F10 command to Midnight Commander:

screen -p mc -X stuff \033[21~

The console command line in mc shows 033[21~ after the command prompt, as if I had typed those letters directly myself. Chances are I’m feeding it the wrong commands, or there is some other special switch that I need to add to get it to actually send through as a keystroke instead of raw text.

I could probably just use screen’s default kill switch (CTRL+A CTRL+\) to close everything, but I don’t know if I am comfortable with that. Given that these commands are available and work for some cases, I probably just need a nudge to get the whole thing working as imagined.

A console spellchecker and dictionary

My list of stuff to write about seems to get longer and longer every day, instead of shorter and shorter. I just got done explaining four console “tools” that lack real interfaces but are still useful, and I could probably come up with three or four more posts similar to that.

But two things that I have failed to mention for quite a long time now — in fact, three things — are a dictionary and spellchecker for the console. If you write as much as I do, those two things are important, and not wisely left out.

In my case I needed two things that would work well with charm, because that’s where I do all my dirty work. For a dictionary, the dictd package works perfectly.

dict sends its results to stdout, so I can pipe that into a text file if I want, or directly into vim. The real value (for me, at least) is in the thesaurus; I can’t tell you how many times a day I’m trying to hunt down a word that means something like “this,” but not quite “this.”

What you see running there is actually an earlier version of dict (1.10.0 to be exact), because the newer versions pick up a dependency (libmaa, or something like that). I prefer to build just one package, if I have to do it at 120Mhz.

For my purposes, aspell works fantastically with charm.

I added the aspell-en English dictionary, although there are dozens available, depending on your distro. I cue aspell from the charm posting menu, and the aspell interface pops up.

Available commands are visible at the bottom of the screen, and adding a word throws it into your personal dictionary in your home folder — and that’s something you can directly edit, in case you want to add things on your own. Since most of my posts have HTML coding in them (yes, all by hand), I have already added a few words like “href” and “img,” as well as “Ubuntu” and “distro.”

charm itself will give you the option to revert from a spell-checked post, which means if you kludge something up, you can get back to your original without too much sweat. These two work particularly well together.

The last thing I wanted to show is already visible above. This is most, which is pager of considerable style, when compared with less or more.

Split windows, search functions, text marking, help page and a lot more. As you can see it makes it a lot easier to scan through different parts of a document at the same time, or compare long lists without needing two pagers running concurrently. Depends on libslang2, but that’s not a huge sacrifice.

I think that’s about it for now. I can cross three more things off my “to-write” list. …

Potamus: The way software should be

I like sparse software. I like programs that do one thing. I like applications that don’t try to manage my life or my schedule or my music. I want clean interfaces with straight lines and no rubbish. I don’t want glitz, I don’t want frills, I don’t want glossy album covers fanning out between tunes, all hovering over a mirrored backdrop. And I definitely don’t want one-button clickable interfaces to social networking sites owned my multimedia conglomerates.

This is what I want.

Meet Potamus, found by accident while digging around on Adam Sampson‘s site. (Adam is the author of both rawdog and cdsuite.)

Now this is an application I can appreciate. Start. Drag and drop. Play. No more menus or options than is necessary. One button to clear the list, a few more to mimic the same audio playback controls that have been standard since around 1968, and a few audio presets … just so you can’t complain that it’s featureless.

Source package is a mighty 124Kb, so with a few extra dependencies here and there for the file types you enjoy, it’ll run in a slice of memory about the thickness of your fingernail. I daresay I like this even better than Alsaplayer.

In AUR. In Ubuntu.

This is the way software should be.

Crunchbang and Archbang

Since I stepped up to a slightly more modern computer, I have shifted the majority of my distro-hopping expeditions to virtual machines. Having two cores means I can usually still meddle in other matters while watching an ISO boot in Qemu. And it saves a few steps in burning a CD, rebooting, tinkering with the live environment, then returning to an installed system.

But let’s face it: Emulated systems just aren’t anywhere near as fun as the real thing. Distro-hopping in a virtual machine is like drinking sugar-free cola … where’s the fun in that? And it tastes strange too.

So here are two real-life systems running live CDs, forming an unusual pair — Archbang and Crunchbang.

 

These are both prereleases — Archbang is the 2.00 RC, and Crunchbang is the Statler alpha — but I’ve modified the default desktops a little bit. Must show something new, right?

The ‘bangs are popular these days and have been for a while. Crunchbang has a reputation for scooping Ubuntu users who find the default arrangement a little heavy, while Archbang is a relatively recent offshoot to do the same thing, just with Arch Linux. As you can see they’re not precise duplicates, but rather different approaches to doing the same thing.

This Crunchbang release will be the first built from Debian, if I understand correctly. It incorporates a healthy shake of Gnome, but it seems quick and speedy, even off the CD. Of course, using Gnome doesn’t mean it has be sluggish and bloated, it only means that some renditions will be sluggish and bloated.

I could recommend any number of substitutes to things like gedit or Thunar, but the fact remains that if those are the applications the Crunchbang community wants, that’s what they’ll get. Don’t want Iceweasel? Put something else on there, I say. As it stands the theme is coherent, it runs fast, I had no hardware issues and short of installing it, everything worked fine while it floated in RAM.

Archbang is interesting as well, but I don’t want it to sound like a footnote. The software selection is markedly different — Chromium is in place, for example, and Exaile is the media player on hand, and so forth — so I am not sure if the idea is to mirror the Crunchbang desktop with Arch as the foundation, or just to provide an analog between the two root distros.

Either way, I suspect that building a system to duplicate Crunchbang or Archbang in either Arch or Debian would only take an hour or two, so you could say the time saved is small. But both systems would be good starting points for building your own Openbox desktop, adding or subtracting the software you like and using their configurations as frameworks.

So the real question becomes: Which do you prefer, Arch or Debian?

No gift for gab: Four more console tools

Usually I focus on console programs that include an interface of some sort. The reason for that, as I have said before, is because there really isn’t much difference between GUI programs with buttons and menus, and a console application that arranges things visually and cues you from that interface. The long, long list of available audio players for the console should be illustration enough of that.

But I need to get past that sometimes. After all, there are programs whose “interface” is so exceedingly sparse as to be … practically nonexistent. Sometimes that’s because there’s no need for an interface — the program just does what it’s told, and finishes. Other times its because the author was even more of a minimalist than me, if you can believe that.

Here’s an example: wcalc.

As a command-line calculator, you might prefer this over bc, although they both rank around the same in terms of loquaciousness. If there is an interface to wcalc, it’s the arrow prompt and the terse greeting. Entering the question mark key does give you an idea of exactly how far wcalc can carry you, but it does a good job hiding its potential.

Of course, puf makes wcalc look blabby.

As if the world needed another file retriever, you’re thinking. Yes, I suppose that’s one opinion, but puf is clever enough to run its fetches in parallel, and can recurse through a site and filter targets, and can even follow links to sites beyond its target (which is either good or bad). It’s always possible that wget or some other download tools can do some of these things, which means puf isn’t quite as special as I might make it sound. But imagine you want to mirror a site locally. …

Either way, puf’s statistical output is about as close as you’ll get to an interface, and if you want less than that, you’ll have to tell it to be silent. Depending on the target and your bandwidth, it will probably only be on the screen for a short while anyway, so enjoy it while it lasts.

Another funny little tool is hiding in the cdrkit package — dirsplit.

If you’ve ever wanted to shuffle files between directories according to size of the target (like a USB drive or a CD), this is probably a good tool for it. By default it writes mkisofs catalogs, to show where files should be moved to fit your constraints. You can also direct it to move those files expressly, and save yourself a step if you’re shuffling files across volumes.

But talkative it is not. An interface is … well, not really there, unless you count the verbose output, which I don’t. One last tool … atool.

Another one that doesn’t talk much, but does seem to have a useful place on a Linux system. Everybody has their own form of compression, and atool tries to tie them all together in a cohesive way. It’s (generally) smart enough to determine which decompression program to use, and feeds it the flags that match the instructions it received. So whether you’re working with zip, rar, ace, tar or whatever files, you won’t (or at least shouldn’t) need anything but atool to empty them all.

There are literally thousands of command-line gems like this out there (here‘s a great list), and dismissing them out of hand because you can’t stab at them with a pointer is rather shallow. I’ll try not to be equally shallow, by dismissing them out of hand because they don’t impress me with their interface. Or lack thereof.

P.S.: puf is the only thing here that seemed to be absent from both the Arch and Ubuntu repositories. So you’ll probably have to build that one on your own. …

Restoration of the week: Remy’s Datamini PA40

Today I have permission to share a few pictures from Remy, who has restored an ancient Datamini PA40 and needs suggestions on software for a 286-based machine.

  

Remy says the insides include a 12Mhz processor, an EGA color display, 655,360 bytes of memory (that’s 640K, if you’ve forgotten the conversion), with no extended memory and a 44Mb hard drive using some sort of compression. DOS 5 is apparently on board, and uses only 88 bytes while running. ( Now that’s lightweight.)

The photos show Hack (not NetHack — Hack) for DOS running, and Remy said he also found Adventure, Tetris, Rogue and a Boulder Dash game, but the last one didn’t seem to recognize the arrow key input. An editing program called (not surprisingly) EDIT is apparently also available.

I love projects like this. The best part is this photo diary showing the disassembly, scrubbing (literally) and reassembly. It might be amusing to think of scouring circuit boards and casings in your bathtub, but trust me on that point: It’s usually the easiest way. If you have a machine and you’re wondering how to rehab it, this is a fairly good tutorial on ripping one apart and putting it back together, too.

Remy said Slackware 3.3 boots from floppy but hangs at LILO, FreeDOS/Balder hangs at start too, and Minix 2 also fails. PocketLinux prints a message asking for a 386 or higher CPU, and a few other generally-recognized-as-low-end distros seem to draw the line at the 386. If you have any ideas or suggestions, I am sure Remy would be thankful, and I would be curious too.

In the mean time I’ll be kicking myself for turning down a leftover 286 machine about a year ago, mostly because I wasn’t sure I could get anything done with it. I don’t know why, but apparently I forgot that the point isn’t always to get something done. Sometimes it’s just, as Remy said, that “a modern core2duo does not have the charm of my 286. ”

Another one-disk wonder: DexOS

At times I am still amazed by Linux distros or even full-blown independent operating systems that scale down so completely and cleanly as to fit on a single floppy disk. KolibriOS was one, and I make a point of keeping that around as a note of what is possible with so little, and on nearly any hardware.

I got an e-mail a day ago that reminded me about DexOS, which is another one-disk wonder. You’re probably still wondering what the point is, when floppies are so far out of date as to be completely irrelevant. Well …

 

What you see there isn’t even DexOS’s main goal, which is to serve as a kind of media platform if I understand it correctly. An entirely different GUI is what you get on startup, which you can get a look at in the screenshot gallery (I had some screenshot issues, hence Qemu … sorry ). In the space of a floppy — scratch that; in less than the space of a floppy, because the running system reports only a hair over a megabyte used, there are a couple of arcade games, a media frontend, networking and USB frameworks, a Web server, a basic Windows-esque GUI, screensaver, gif/jpeg/bmp support and more.

Looking at home page, there is more available with the goal of allowing you to build a few things on your own. The forums show a rather active community too, with posts and replies within the past few weeks, along with screenshots of a promised version. So this isn’t a stalled project, by the look of it.

It’s definitely something that will require a little elbow grease though. KolibriOS was for the most part an entire desktop compressed into a floppy, where DexOS obviously has a different goal in mind. Don’t expect to fire this up on your Pentium II and watch YouTube videos over your wireless connection. A tool for every job.

Check out the wiki if you think this is appealing, or if it might work as a platform for your own personal attempts to conquer the world. I can at least promise that it won’t monopolize your system resources, like some operating systems can.

Rubbing shoulders with giants

Hello and good morning to the kernel.net Linux news aggregator, which asked my permission to include the feed for this site in their collection. Looks like I’ll be rubbing shoulders with the likes of Phoronix, WebUpd8, The Register, opensource.com and some other very impressive sites.

Geez, I better clean my act up.

Just for the record, everything I publish here is licensed under the GNU Free Documentation License version 1.3, which in a nutshell means it’s freely reproducible and translatable (take a look at the About page for more details). You are more than welcome to include it in any aggregator or feed, and although it is exceptionally polite to ask my permission , you don’t need to. Please feel free.

In the mean time, I’ll be reviewing everything I ever posted over the past four years with a considerable degree of embarrassment. Oh dear. …

At long last: A look at vifm

I’m not a huge vi/vim fan. I use vim on a daily basis for editing text files and for writing up blog posts, but I have no passion for it one way or another. I know how to use the basic functions, I can search and replace, I have screen wrapping without inserting line breaks, and so forth. I am a casual user.

And I can say that about most any console text editor. I know how to get myself into and out of emacs, but what it does beyond text editing doesn’t really enthuse me. I started out with nano and in my humble opinion, that’s the easiest on the new people. I even have a handle on some of the more obscure editors, like joe or e3 or even some built-in editors in other programs.

My point here is, I am not one of those people who goes looking for vi-cloned software because I like the keystrokes, or the command system or the philosophy. I am more than capable of picking up something completely alien to vim and learning how to use it.

On the other hand, vifm does have a certain appeal.

ncurses-based, quick and speedy, spartan, functional, not frilly or overburdened. And the “appeal” I mentioned might just be the logical analogy between the text editor and the file manager.

For example, typing dd while a file is highlighted deletes the file. In vim, the same keyset — dd — deletes a line of text. The navigation keys in vi — which I believe hearken all the way back to the prehistoric age of computing — work as navigation keys in vifm, with the left and right commands pushing up or down in the folder tree. The double-y command yanks a file, and p pastes it back into place, for an efficient and obvious file-movement sequence.

The man page for vifm will tell you everything you need to know, and the :help command — a godsend in vim — might also give you a few clues (the Arch version is hiding somewhere though ). But of course, and the real point of this is that, if you’re already a vi/m user, you won’t need a man page to get started. You should know, or be able to deduce, most of the commands from the first starting of the program, and without too much struggling.

Beyond simple navigation and file movement though, the :com command is what you will probably like most of all. I only barely scratched that point, but that seems to be where all the fun stuff is.

vifm is a good deal lighter than mc, and if you’re one of that dying breed, the Unix purist, vifm will probably appeal to your sense of philosophy too. I can give it a thumbs-up as a clean, fast, precise tool that you can learn in a matter of seconds if you already know the basics of vi/m … and in only a matter of minutes if you don’t.

For my own part, I am steeped in the days of Norton Commander and its progeny, so I believe I shall stick with Midnight Commander. It just feels right for me, and like I said, I am not so much a vim proponent that I find vifm overwhelmingly preferable. Check it out and make your own judgement though. It’s all about freedom.

Sound’s ironic

I still spend a little time — now and again, but not often — trying to resolve the long-standing sound issue on my Crux-driven Pentium laptop. It took me years to find out how to get any sound at all out of it, and now that it is working, I would really like to have solid, clean playback instead of skipping and pausing so frequently.

But to be honest, it doesn’t look like that’s going to happen — not like it ever really did though. I spend a little less than an hour this morning setting up mpd and ncmpc following the howto at nepherte.be. It worked for Crux as well as Arch, which came as no surprise. Technically the howto is for ncmpcpp, but ncmpc is in the Crux repos so I went with that. (For the record, building both mpd and ncmpc at 120Mhz took only about 30 minutes, plus or minus. )

Everything is working fine, but playback still sputters and pauses, much as it did in Debian with the same setup, or in Crux with mocp, or even with Orpheus — although to be honest, that last one was probably the best. mpd is particularly lightweight, but even from a cold boot with nothing but the daemon running, I still get skipping and breaks in playback, with the processor load pegged at 100 percent (according to htop).

What’s a person to do? It seems my best efforts to trim back and trim back and trim back … just aren’t enough. I suppose I could try lighter codecs — these are usually ogg files at a quality level of 7 or so — but to be honest, that adds another layer of inconvenience to the issue. If I was committed to playing back audio on this machine I suppose I could convert my measly 5Gb music collection out of oggs and into a different codec. But mp3 files are the same, plus there’s the conversion time, the transfer over the network to this machine, and ultimately the possibility that it wouldn’t help. A lot of question marks there.

I think what has happened here is that finally I have reached a point of function that has been determined by the hardware. I type to you now on a 14-year-old laptop with a huge array of up-to-date console-based programs and a modern operating system. But the machine itself — the actual hardware — probably just can’t handle the task of converting digital files into music … and since it is barely a contemporary of the MP3 trend (mentally I always equate the rise of MP3 with the advent of Winamp), I shouldn’t be surprised.

So it would appear that the practical threshhold for audio playback falls around 150 or 166Mhz or so. If you can improve upon that, please let me know, just for curiosity’s sake.

Overall, in the grand scheme of things, this doesn’t even register as a loss. It’s rare to find a machine this old any more, and even rarer to get things working to a point where audio playback is possible. But there are thousands upon thousands of machines only-slightly-faster than this one, that can handle the task without suffering. Just kick over a trash can, and pick up another one.

(And just for the record, I do have audio available — for example, centerim pings cleanly and regularly, every time a new message appears. It’s just the difference between that short burst, and a sustained seven-minute song.)

But at the same time I’d be lying if I said I wasn’t a little disappointed. It was a coup to get the thing (or its cousin, technically) running at all, and another coup to get the framebuffer working, and yet another long-awaited coup to get the audio figured out. The fact that it is working only halfheartedly now is … ironic.