One day at work, I got a trouble report from someone who had installed his own version of Google Earth in his home area. He was having trouble with it not starting because of some library error.

Now we support a system-wide installation of Google Earth. And I already recognized the library error that he was reporting. If you are interested it, it is a problem that shows up on at least openSuse linux and is due to the Google Earth included copy of libcrypt being compiled with different options. Move it out of the way and Google Earth will now start.

But my user reported something else in addition. He said that when he was in his installation of Google Earth directory "ls -l" gave a similar error, but "ls" with no options didn't.

This was a bit of a head scratcher, as the first thought I had was, "This sounds like a case of having '.' in his LD_LIBRARY_PATH." I couldn't think of any good reason to ever have "." in your LD_LIBRARY_PATH. Worse, I am well aware of the security risk of having "." in your shell's command PATH. I was afraid that I'd just stumbled on a whole new class of potential security issues with replacement libraries.

So I popped in to check on my user. I let him know that I'd already fixed the same problem in our version of Google Earth, which he could have just for asking. But why did he have "." in his LD_LIBRARY_PATH?

It turns out that he didn't have "." in his LD_LIBRARY_PATH. What he had was an LD_LIBRARY_PATH which ended with a ":".

It's time to short cut this story now. ":" separated PATH-type environment variables interpret empty fields as if they were "."!

Yes, the "!" is deserved. Having a hanging ":" at either end or a "::" somewhere in the middle of your shell's command PATH variable gives you a "." in your PATH without you meaning it. Worse, it is hard to see.

I didn't just stumble on a new class of security issues with replacement libraries. I'd also stumbled onto a stealthy way to sneak a "." into a user's PATH variable, with all the known security problems that entails.

Bash or tcsh. OpenSuse, SLES, Kubuntu, Red Hat, IRIX, Solaris, FreeBSD. Arg! Was this documented somewhere? Is this the way it is supposed to be?

So far, no one I've told about this was aware of it.