Trim the PATH by jailing applications

Path explosion is a real annoyance and if you’ve had your [windows] box running for a few years, you know what I mean.

It seems every other program considers itself to be the most important in the world and deserves a slot on the extremely scarce PATH resource (on windows 260 characters!).

If you haven’t found a solution yet after trying countless options, take a peek at this.

Normally we are left with three options to choose from.

1. Having every app that has a command or two that we want to use reside on the path, but that also drags in a slew of stuff we don’t want. In addition, on windows the apps that are relegated to the end if the path won’t be found or executed at all once we reach 260 characters. If that happens to be the core windows directories c:\windows\system32 and the like our system becomes unusable.
2. We can omit the program from the path and be left with typing c:\program files (x86)\long vendor name\long product name\version\finally\the-command every friggin time we need to execute the command.
3. We create a batch file for each program and store that in a common directory, and that works until some program calls our batch file thinking it’s a real executable and the concept collapses and the evening is soured.

Remedy !

To address this DLL PATH H*LL I took a cue from the wonderful HomeBrew package management system for Mac OSX. The notion there (and on OSX in general) is to install everything an app needs in an isolated directory and then expose as little as possible for global consumption. Having less stuff piled on top of each other naturally leads to a cleaner and simpler environment.

So with that core principle I thought, why not apply the idea to the cluttered mess called Windows/Linux ?

The remedy then is the notion that NOTHING should be on the PATH that I don’t want there. To achieve that I created a command wrapper that will act as another command, that is configured in a certain manner and residing at a specific location.

This simple construct allows me to shove git, mingw and a host of other stuff into their separate jail cells (isolated directories) and then in a single directory that I add to the Path, create copies of (or windows hard-link to) the command wrapper renamed to the command of the actual program that should be launched when invoked.

This allows me not only to launch the programs indirectly, but also reconfigure them to an extent, by temporarily modifying environment variables before launching the actual programs. What the wrapper finally delegates to and how it delegates is controlled via one single and simple configuration file with one line per wrapped command / program.

I can version control that file, switch implementation that is being delegated to by editing a line in the config file and thus have multiple normally conflicting copies of a program on the system. And these are real executables that won’t fail when called by some application through exec or CreateProcess.

Finally, some may think “so what, why not just use a batch file” to which I’d respond if that works well for you, sure ignore this stuff. But if you’ve had issues with that approach then feel free to try this one and see if it works for you. If you’re undecided and haven’t tried the batch angle, then here are some points to consider:

• There are a lot of situations where a batch file behaves differently from a real executable or just plain doesn’t work. This is especially relevant when programs invoke other programs. Having a real executable is a real boon there.
• All configuration is managed in a central location, in an easy to read and understand syntax, instead of sprinkled out in different bat scripts where each bat file needs to be maintained.
• Launching a binary executable is faster than a batch file, as the command line interpreter does not need to parse and interpret a script.
• This is a portable solution that works the same on OSX, Linux and Windows, which is not the case for batch files.
• You don’t get the tedious “Do you really want to abort (Y)es/(N)o” question whenever you CTRL-C out of a wrapped program, as you do with batch files.

Ahead

In an upcoming version I’m contemplating streamlining the configuration management as well, so that the setup consists of one step instead of two (linking / cloning the wrapper and adding a line of text to the config file). Something along the lines of

cwrapper -alias C:\Progam Files (x86)\software\foo.exe

cwrapper -alias C:\Progam Files (x86)\software\bar.exe -with TERM=xterm

And that would create a symlink on *nix and hard links on Windows to the wrapper with the same base name as the program being aliased and create or update the configuration line for you.

But for now I’m content with the initial implementation where I edit the config file by hand as it’s even less typing than the above examples. Though if people request more features I’d be inclined to enhance the program.

For compilation laymen I recommend compiling from source.
And for those without compilers / non-programmers, binaries are provided for Linux, OSX (intel) and Windows below.

file: cwrapper-0.1-linux32.tar.gz
SHA1: de6f069a0d58741fb06badd802e1e7cd0260901e

file: cwrapper-0.1-osx-10.8.tar.gz
SHA1: 65bd943fc16605d99f0a6de22fbe6e302776ebcc

file: cwrapper-0.1-win32.zip
SHA1: 737beec6a96bca9731e0c7947f06bf397f4735d8