Environment variables in Linux

Ok, one of the first problems I encountered getting back in Linux is the management of environment variables. As a developer I am used to testing lots of new stuff, leaving the comfortable cushion of the click&install paradigm that the latest distributions try to deliver. But by doing so I don't want to sacrifice the few things that really make sense, like simply running an application compiled by hand from the RUN prompt that usually is invoked with ALT-F2. Or, even, to have an icon for said application posted in the desktop folder.

Things are not so easy, of course, you'll find to your amazement. As we know, UNIX environments are quite flexible: so flexible, in fact, that it's impossible to have a consistent behavior.

What happens if, for example, I set up a local installation folder for the software I compile (in this case, codelite). For the software to run I need at least two things (or three, in this case, but we'll settle with only two as well):

1. The PATH variable should contain my local bin folder /home/spooky/local/bin, and
2. Either the LD_LIBRARY_PATH or the ld.so.conf (the linker configuration file) should contain the library folder /home/spooky/local/lib.

Fairly easy, but virtually no solution will make me run the application from my current graphical shell without a log-out/reboot in between. Why is that?

Probably because the Linux desktop environment is fairly complex, and it has no unified logic or structure. Desktop environments differ a lot and can become quite confusing for a user. Just take a windows-user and put him in front of a WindowMaker desktop. Then congratulate yourself for the idea.

So what's the solution? The help page I found most intelligible and easy to understand is the "Environment variables" from the Ubuntu help pages. There we find that the right location for these variables may be (but we're not certain) either in /etc/profile.d (if you create there an entry that will contain the definitions of PATH and LD_LIBRARY_PATH, make sure you name it whatever.sh) or in the ~/.profile (better, but not system-wide, only user specific).

Ok, what's missing? First of all, even after you will corrupt the profile file with your evil entries, you will need to restart - running the application you want from the ALT-F2 run prompt will not work (yet) but running from a terminal will. The reason is that the desktop environment is not and will not be aware of the change until you log-out and then reinitialize the session. Groovy, isn't it?

Theoretically, such a problem would be easily solved for a desktop environment, since all the processes are spawned from the same base process. In Windows, this is a lot easier, since the environment is controlled and the spawning process, explorer.exe, is the same that does a lot of other things - implementing the change of an environment variable on-the-fly is very easy (you can do it from somewhere around the My Computer Properties page).

Why nobody in the Linux community would create such a feature? Well, aside from the technical impossibility of offering the same feature over N desktop managers (a practical impossibility, with tens of combinations that should be maintained), it's actually the number of possible locations for such a variable that would make it confusing for such an implementor to create it. Do you want it in /etc/profile? /etc/profile.d/*.sh? /etc/bashrc? /etc/bash.bashrc? /there/and/back/again? Too many options sometimes it's just that. Too many options.

Of course, there are some prospects for such a feature. It could be implemented. Who needs it, tho'? Only picky programmers that don't want to log out of their system. Probably no user would ever and should never touch system variables - they are there just for us, for the developers.

As a conclusion, since there is no user friendly way for the users to modify a system variable, one should always make sure that his program doesn't need it. Relying on the capacity of the user to modify system intimate features like this should be avoided. Forcing the user to such dramatic actions like logging off or rebooting should be forbidden for any installation of your program. No matter the reason.

The only way that a programmer should use environment variables should be to respect them, act accordingly to their meaning (if their meaning is useful to one's application), and make sure that they will not add extra-requirements from the environment unless the programmer really really really really (have I said it enough times?) really really knows what he does.

Even if it's just because we don't like to wait while our computer reboots.