Those Pesky Applications!

Regardless of which operating you’re using, you’re bound to encounter applications that cause you problems. Some applications cause you problems so often that you eventually place a custom launcher or even a keyboard short-cut to a command that kills the applications. Firefox used to be one, but since version 3, it’s been much better. I still have problems, though now it’s always related to the Flash plug-in (which is rather troublesome in 64 bits mode). Another one that cause me problems regularly, is EvilEvolution, the Exchange client for Linux.

One essential *nix command you should know, is kill. The kill command dispatches a signal to a process, by default, SIGTERM. This message instructs the process to terminate. It can ignore the signal, but in general, it will close gracefully after freeing resources. If the program ignores the signal or is in an unstable state, you can kill it “harder” by using kill -9, which sends the process an unmaskable SIGKILL. The process terminates instantly under most circumstances.

Sleepless Koala

A few days ago, I changed my machine and upgraded to Ubuntu 9.10 (Karmic Koala) and everything went fine, except for the screen-saver that would activate properly but not switch the screen into sleep mode after a while. I found a couple of fixes because despite being a documented bug, there’s not definitive fixes yet.

Affinities and ulimit

The Bash ulimit built-in can be used to probe and set the current user limits. Such limits include the amount of memory a process may use or the maximum number of opened files a user can have. While ulimit is generally understood to affect a whole session, it can be used to change the limits of a group of processes using, for example, a sub-shell.

However, the ulimit command is quirky (it expects a particular order for parameters and not all may be set on the same command line) and does not seems to be ageing all that well. For one thing, one cannot set the affinity of processes—indirectly controlling the number of and which cores one can use in a multi-core machine.

Is Python Slow?

Python is a programming language that I learnt somewhat recently (something like 2, 3 years ago) and that I like very much. It is simple, to the point, and has several functional-like constructs that I am already familiar with. But Python is slow compared to other programming languages. But it was unclear to me just how slow Python was compared to other languages. It just felt slow.

So I have decided to investigate by comparing the implementation of a simple, compute-bound problem, the eight queens puzzle generalized to any board dimensions. This puzzle is most easily solved using, as Dijkstra did, a depth-first backtracking program, using bitmaps to test rapidly whether or not a square is free of attack¹. I implemented the same program in C++, Python, and Bash, and got help from friends for the C# and Java versions². I then compared the resulting speeds.

Log Watching

Very often, you have to keep an eye on a log, or maybe more than one log, and a couple of other things while a long-term simulation is running. The GNU/Linux distributions offer the program watch that allows the periodical execution of a command in the current interactive shell. While watch is convenient, you still have the problem of displaying the needed information in a terminal geometry aware way. Turns out, there are tools to query the terminal geometry and we can use them to write simple, effective, well displayed scripts.

So let us see how we can make BASH somewhat aware of the terminal it runs in.

A quick Bash Fix

Remember, not too long ago I told you how to shorten path names in a Bash prompt? Well two things. Apparently, there’s a similar mechanism in Bash 4.0 with PROMPT_DIRTRIM(which I haven’t tried yet). Second, noticed that I’m frequently using many terminals opened on many machines, and I’m not always sure which is which. Using uname -n in the terminal spews the machine name, but it’d be much better if the name appeared in the terminal title bar. To do so, use the same prompt I used previously, and add $HOSTNAME (a Bash variable that holds the machine’s name) in there:

PS1='\[\033]0;$HOSTNAME: $(shorten_path "${PWD}" 50)\007\]$(shorten_path "${PWD}" 50) >'

(again, use the view plain mode if WordPress messes up the syntax again)

Short PWD in BASH Prompts

It’s not uncommon to have inordinately deep directory hierarchy on your computer, especially if you’re like me and you like to give significant names to your directory. For example, if you’re using a 80×25 terminal, the location /home/steven/download/Album Photo/2009/06 jui/20-22/21-008-St-Georges-de-la-Malbaie will cause your shell prompt to wrap around the shell window quite messily. Of course, you could show only the last directory’s name, say 21-008-St-Georges-de-la-Malbaie to continue with my previous example, but that’s a bit terse, especially if you end up on a directory whose name is unexpectedly short.

The correct solution, may be, is to arrange the prompt to show adaptively long parts of the current working directory up to a given limit, and abstract parts of the path using, say, ..., and make sure the result is legible. For example, /home/steven/download/Album Photo/2009/06 jui/20-22/21-008-St-Georges-de-la-Malbaie, using a maximum prompt length of 50 would get shortened to .../06 jui/20-22/21-008-St-Georges-de-la-Malbaie, which is already much shorter yet retained its legibility and meaning.

Suggested Reading: Beginning Portable Shell Scripting

Peter Seebach — Beginning Portable Shell Scripting — Apress, 2008, 352 pp. ISBN 978-1-4302-1043-6

(buy at Amazon.com)

This book, like Bash Cookbook: Solutions and Examples for Bash Users isn’t overly technical. It focuses on one particular aspect of shell scripting, portability. While no one really expects a bash script to be excuted using a different shell, such as zsh, for example, Seebach shows us that there are ways to ensure that the scripts behave reasonnably well when executed in different environments and by different shells. Seebach presents various shell constructs and discusses their portability, giving numerous examples.

Spiking Makefiles with BASH

The thing with complex projects is that they very often require complex build scripts. The build script for a given project can be a mix of Bash, Perl, and Make scripts. It is often convenient to write a script that ensures that all the project’s dependencies are installed, of the right version, or that builds them if necessary.

We often also need much simpler things to be done, like generating a build number, from within the makefile script. If you use makefiles, you know just how fun they are to hack and you probably do the same as I do: minimally modify the same makefile you wrote back in 1995 (or “borrowed” from somewhere else.) In many cases, that makes perfect sense: it does just what it has to do. In this week’s post, I show how to interface (although minimally) Bash from Make.

First Impression Fail

It is said that first impressions lasts forever. Well, I sure hope these first impressions won’t keep me from using Solaris in the future. So, yes, I decided to try out Solaris, and I downloaded the VMWare virtual machine images from Sun. First there’s the usual annoying questionnaire about who you are, what you do, why you want I to try Solaris. Everything short of my income and investment strategy.

So I download the file with what seems to have the biggest version number, but it turns out that’s only the second half of the virtual machine. And it’s a stupid tar bomb. OK, I reread the thing, and there’s no clear, visible indications that there are two parts to the tar ball and that I should download the two. Never mind that, bandwidth’s is cheap.