I find one of the worst aspects of managing any OS is trying to figure out who finds what resource where. For example I just spent about an hour trying to figure out why I don't get a color coded ls in the konsole shell when logged in as root. Works fine for any other user, and works when I ssh into another box from the konsole. This problem is actually trickier than many such problems. Problems can often arise when we install or remove software from a system. We may inadvertantly remove, overwrite or mask a file or setting used by another application. There is a long-standing tradition of dumping things in common locations such as /usr/bin, /usr/lib /usr/X11R6/bin etc. This is generally a bad thing. There is also a tradition in Unix of constructing the directory tree for an application with this type of structure: /$app_home/{bin data doc include lib man share} This is very good. We can add the executables to the $PATH variable without cluttering up the /usr/bin. (There is, of course, still the problem of having app_A/bin/runme and app_B/bin/runme. Now if we enter *runme* on the command line we hit the first runme we find, not necessarily the one we expected, or wanted.) We are now capable of having a script, say /etc/profile.local which can loop through /, /usr, /usr/local, and /opt, looking for directories with the name *bin* and adding them to the $PATH. If we wanted to make sure one came before another we could have a prioritization system built into the script. For myself, I don't like path type variables because they are hard to read, and they leave me with the feeling that things are haphazardly accomplished. One of the things I hate the most is to see the same value appear in a path variable more than once just because everybody and his sister thinks it should be there so they all add it, or because every time a certain program executes it sources a file which adds the variable yet again. I haven't tried to write it yet, but I'm sure a little ansatz could be created in bash which could check for the existence of a particular string in a path variable and make modifications according to the results of that check. What I really like is the way ldconfig works in conjunction with the /etc/ld.so.conf. That is, however, still static and requires modification when a new lib directory is added. Why not just sniff for them? If there is a problem with 'masking' where two files have the same name and the one that comes first is used even if it's the wrong one, add a mechanisim to prioritize these. We might even be able to modify the related databases 'on the fly' as needed. I am currently experiencing some rather strange things with TK and XEmacs where I'm never sure which widgits XEmacs is going to be using when it starts. Sometimes it's light gray, and sometimes it's dark. Very strange! Another issue is the problem of finding out who (what script) set a variable, where it was set, and even who else wanted to set it but found it there already. This is really a big issue when one script goes in and changes a variable that another script has set. The administrator sets the variable where he or she thinks it should be set, and some other script changes it. There should be logging taking place when these variables are set. Either the scripts themselves should be logging the actions, or bash should be doing it for us. My guess is, the former is much more realistic. I strongly believe applications can and should adhere to standard methods of presenting their resources to the rest of the system. This should be done in a passive way. That is, the application's installation should not modify anything outside of its own directory tree except, perhaps to add its own directory to /var or /etc. Such modifications as these should be made in standard ways. If an application wants to set an environment variable it should have a config script available for the system to run during the configuration process. This is similar, but not identical to the way SuSE currently works with the /etc/rc.config.d and /etc/profile.d. perhaps each application should have a <$app_home>/config/{config.sh profile.sh someother.sh} These could be visited by the /etc/profile.local I'm sure I've just stepped on some one's favorite assumption about configuration management. I would love to hear what others have to say on this subject. Any thoughts? Steve