dvtm - a console based tiled window manager

In my last post, I outlined how to do some form of rudimentary multitasking in Bash, but I was still not satisfied. Further research showed that there would be no way around a terminal multiplexer, however screen sucks for me due to its steep and unintuitive learning curve. On K.Mandla's great blog I found the solution: dvtm, a very lightweight tiled window manager for the console. Its beauty lies in that it occupies just around 100k of disk space, does not hog the memory and does not try to accomplish more than it is supposed to.

Becoming familiar with dvtm is a matter of minutes. Install the package from your distribution repositories, go to a console or open an xterm, then input dvtm. You will see Bash within a blue frame. The blue frame indicates that this is the active window. Now press CTRL-G C (press CTRL-G, release the keys, then type a C). A new Bash window pops open next to the existing one and becomes the active window. You can close that window by either logging out of that instance (input exit or press CTRL-D), or by pressing CTRL-G X.

With multiple windows open, you can input CTRL-G <number> to activate window <number> (as designated by its "title bar" text), or CTRL-G J / CTRL-G K to activate the next/previous window. CTRL-G . minimizes or unminimizes the active window. CTRL-G M maximizes the active window. Use CTRL-G SPACE to toggle between grid layouts; this is also the only way to unmaximize a window. CTRL-G ENTER moves the active window in and out of the "master area", which is usually the tile of the biggest size. Finally, dvtm can be left by means of CTRL-G Q, or logging off all hosted shells.

If you need a lightweight multi-window shell environment, dvtm should be surely worth checking out.

How to work with multiple jobs in Bash

An important feature often overlooked by novice console users is job control. It allows some amount of multitasking on a shell by delegating processes to the background and resuming them at a later point. That way, you don't have to launch a second shell or use additional utilities like screen to manage multiple tasks.

Job control is easy. Let's say you have Midnight Commander running. Hit CTRL+Z and you end up back at the shell prompt. You will notice a line above the prompt stating that mc is suspended. The beginning of the line shows mc's job number in square brackets (1 in this case). Ok, let's use that job number to resurrect mc. Input %1 and voíla, mc is back! Similarly, you can use %1 & to unsuspend mc and continue running it as a background job. Note that background jobs are detached from the terminal and will be suspended as soon as they try to read from or write to it.

When working with multiple jobs, you will find the jobs command very useful, which lists the running jobs with their numbers and status.

A more intuitive way to unsuspend a job is to give part of its command line. %mc will unsuspend Midnight Commander, however if you have multiple instances running it will result in an error. Finally, just inputting % will unsuspend the most recently suspended job.

As you can certainly see, this feature is a real time-saver by allowing you to get running applications out of the way and resume them later.

How to recover lost data on an ext3/4 partition

I recently had a late-night oopsie with tar, overwriting the file I wanted to package (source code I had worked on for a week). After a few seconds of creepy feelings, I remembered that I use a journaling filesystem and thus, there would be a good chance that there would be several copies of the data still physically lying around on the storage medium.

So, what to do when you lost a file? For your first action, you have two options.

First option: Power off the system without shutting it down, then boot from a live CD. The foolproof option.

Second option: If you can ensure that no new files will be created on the filesystem where the loss occured while you are trying to recover the data, you can work from the running system and avoid further potential data loss from uncleanly powering down the system.

Next, become root and grep the filesystem where the data loss took place.

grep -a -B300 -A300 "searchString" /dev/sdb1 > dumpfile

searchString is a piece of text that preferably only occurs in your lost file. Try to be as specific as possible so you ideally only get results from the file's contents. The -B and -A options specify the number of context lines to output before and after each match. Choose values large enough to include the entire lost file, if possible. Replace /dev/sdb1 with the device node of the filesystem where the lost data is. You can find out the node by just running mount without parameters. dumpfile is the target file containing the found text. Of course the dump file should not be saved on the partition where you lost the data! Save it on another filesystem or a tmpfs if you have one set up. Mounting a USB stick or something for the dump file may be risky because a device node will be created on the root partition, which stinks if your lost data sits exactly there.

After grep is done, examine the dump file with a text editor. If you are certain that it contains your entire lost file in a usable or recoverable state, you can start copying and pasting into empty files, restoring various versions of your file of which a few will probably be current.

Set DRI driver options via the CLI using dritune (updated 2x)

Aaaah, what a nasty cold I catched that I could not blog for ten days. However, I have not been totally idle during that time and found out that enabling texture tiling in the Intel X.Org driver finally not only works properly on my 915 chipset, but gives a breathtaking speed boost! Warzone 2100 is now playable at high resolutions on my netbook with the attached LCD monitor.

No fiddling with xorg.conf is required for this tweak (in fact many distributions don't ship with that file by default anymore, but it is still supported for troubleshooting drivers). What we do today is setting screen resolution and orientation using RandR, and driver options via ~/.drirc. Look into that file if it exists on your system. Yuck! XML! Not very unixy.

Well, there is DRIconf, a GUI tool that lets you view and modify the driver options and also create profiles for different applications. On the other hand, there are people like me who don't like to install GUIs with many dependencies just for toggling one or two checkboxes. In fact, I was astounded by the absence of command line tools for setting DRI options, so I took over that job and created dritune.

Download v0.02 - tarball, .deb package

Copy the dritune script from the tarball to some location in your path. It has xmlstarlet as its only uncommon dependency, so you need to install it from the repository. Starting dritune without any parameters gives you some usage help. Typically you would do dritune list to get the list of DRI options for the first screen, then dritune info <option> to show a description and possible/current settings for an option, then dritune set <option> to modify the setting. There is much more it can do and it behaves very script-friendly. Best of all, it does a great job at keeping you away from XML :-)

Feedback, bug reports and intents of packaging are welcome.

Bugs so far:

• Running dritune on another machine over ssh will retrieve the driver options from the local machine/display and save changes to the remote machine. Baaad! As a fix, run dritune this way: DISPLAY=":0" dritune.

To do:

• Calling xmlstarlet is slow. In particular, it is subjectively slow when dumping all options to stdout, because it is called three or so times per option. Either the number of calls has to be reduced, or all information should be gathered on startup, or some sort of caching should be implemented.
• Fix Bash throwing seek errors when X is running but for some reason not accessible.