Idea: Adaptive shell
I had an idea today when navigating around in the shell. All my work related files are stored in ~/Work. Under that there’s a folder for each project. Sometimes there are multiple variations on a project or project with a similar prefix such as:
- radiopaedia
- radiopaedia-stable
- radiant-sites
When I type rad [Tab] in my shell (zsh) it kindly completes this to radi and gives a list of the other completions since there are several to choose from. I though it would be nice if the shell could learn from the choices I make. So if I generally choose radiopaedia then rad [Tab] would complete to radiopaedia but still show the list of option.
I’m sure there are several other areas where an adaptive shell that learnt from usage patterns could be applied.
Local Package Management with GNU Stow
I’m a bit of a purist when it comes to installing UNIX style software. I prefer to install it via the package manager on the platform of choice (E.g. apt on Debian or Mac Ports on Mac OS X). However these repositories don’t always contain the particular package you’re after or may contain an outdated version.
In situations like these where you end up building the package yourself I used to employ a system where I would install it into a subdirectory within my home directory. I did this because it doesn’t overwrite a pre-existing system installed version, doesn’t require root privileges and permits quick removal. To achieve this I just passed the --prefix option to the configure script before building. For example if I was building vala I might run the configure script as follows:
./configure --prefix=$HOME/Local/vala
Following that with the typical make, make install sees the package built and installed into that directory. The problem with this approach is that for every package you build you have to add the target directory to search paths such as: PATH, LD_LIBRARY_PATH, MANPATH, PKG_CONFIG_PATH. After a while this gets a bit unwieldy. This is where GNU Stow comes in.
Stow manages these separate target directories by creating symlinks into the parent directories. For example to build vala I would pass a prefix of $HOME/Local/stow/vala to the configure script. After vala is built and installed, change to the $HOME/Local/stow directory and run stow vala. This results in symlinks to the files in $HOME/Local/stow/vala being created in $HOME/Local, with directory structure preserved. So if vala installs files to bin and lib these files will end up under $HOME/Local/bin and $HOME/Local/lib respectively.
Stow can also delete the symlinks to support uninstalling. The end result is that you only need to add one extra directory to each of the search paths and custom software can be built, installed and uninstalled all without messing with the standard system and root privileges.
zsh, Cygwin and Insecure Directories
In order to cope with having to use Windows at work I run Cygwin. My shell of choice is zsh. For whatever reason the Cygwin package of zsh installs with a serious of directories that the zsh completion system deems to be insecure and it makes sure you know this. Each time a new shell is opened (in my case through a Windows native rxvt terminal) I would receive the following warning:
Ignore insecure directories and continue [ny]?
Pressing ‘y’ becomes a bit tedious after a while so I decided to track down these insecure directories and fix them.
Stop Vim Completion Searching Included Files
I use vim coupled with the SuperTab plugin for my text editing and auto-completion needs. In some vim setups (E.g. Mac OS X) it is configured by default to search included files when completing words. This sounds like a useful feature but it turns out not to be. It has a habit of searching the include files of system libraries and modules, the keywords of which you rarely want. Its also quite a slow operation as it trawls through all the files. The solution is to add the following in your .vimrc file.
set complete=.,w,b,u,t
This is the same set of flags as the default except with the ‘i’ option removed. See the help for the ‘complete’ option for an explanation of what each flag means.