Patching the Environment for ‘exotic’ Libraries


Every time I add a development library (or any other application) that is not found in my distro‘s repositories, I ask myself how troublesome it will be. If you’re really lucky, it comes in a package (and repository) compatible with the target distribution (like a Debian package or a RPM) and everything is just fine: you install it from the package manager, and that’s it. But if not, you have to download a tarball from some (more or less trusted) location like Sourceforge. It usually comes with a rather well designed set of configure, make, and (sudo) make install scripts that reduces configuration to little more than launching the configuration script, check for any unmet dependencies, add them and rerun the configuration script until they are all met, and then make install performs a smart, standard location install and you’re done. You won’t have the automagical upgrades with everything else, but you can go on with your life.

Then again sometimes you have to install a library (or application) that either has a half-baked installation script, or is incompatible with your distro, or, cerise sur le gâteau, both. And, just to aggravate you just fine, it installs to a non-standard location requiring you to specify include and library paths in your make files or just to invoke the application. And, of course, default location will change from from /usr/local/shared/thislib/ to /usr/shared/include/thislib between version 2.1.5 and 2.1.6, just to make sure to break just about everything you set up.

Read the rest of this entry »

Suggested Reading: Beginning Portable Shell Scripting


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

(buy at

(buy at

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.

Read the rest of this entry »

The Right Tool


On his blog, Occasionally Sane, my friend Gnuvince tries to make a case for Python as a first programming language. He presents Python with a series of bullets, each giving a reason why Python is a good choice. While I think it may be a good choice pedagogically, it may not be a good pragmatic choice when someone is learning a programming language to find a job, as one of his reader commented.

But I think that betting on a sole language to base a programming career on is about as silly as someone mastering only the hammer looking for a construction job. His limited skills might not permit him to find a job, and even if he finds one, he may be confined to menial, unchallenging tasks. To push the tool analogy further, another workman that masters a wide array of tools will probably be more solicited and appreciated in his work-group, and be lead to more and more complex tasks, and more responsibilities within his group. Programming is very much the same: sometimes, it just takes something else than a hammer, and the right guy for the job is the guy that has the largest toolbox—the one with the Torx screwdriver set.

Image from Wikimedia

Read the rest of this entry »