On Tue, 10 Jul 2007, Mike McCarty wrote: >> On Monday 09 July 2007 20:24, Mike McCarty wrote: >> >>> John R Pierce wrote: >>> >>>> I prefer it the way it is. makes it easier to run multiple instances >>>> without having to copy the binaries. >>> >>> Not necessary at all. For such kinds of work, one normally uses >>> a soft link. >> >> Hmm. If you use a link then which is the directory in which the executable is >> stored? Is it the same irrespective of which directory you're working in, or >> does it differ? Doesn't this muck up the whole idea of working with files in > Brian Beesley wrote: >> the directory where the executable is stored? > > Why would it do that? > > Consider this: > > $ which acroread > /usr/bin/acroread > > $ ls -l /usr/bin/acroread > lrwxrwxrwx 1 root root 40 Jul 12 2006 /usr/bin/acroread -> > usr/local/Adobe/Acrobat7.0/bin/acroread >
It is done in order not to mess a "local" binary with system binaries placed (mainly) in /usr/bin. Question and answer is simple. If you are going to use any "prog" only yourself - put in /home/xxx/bin and add this directory to PATH. If "prog" has to be available to other users - put it in /usr/local/xxx.yyy/package/bin or something similar (my /usr/local dir has attrib "drwxr-xr-x root root" so only root can write to it!) and make soft/hard link as acroread does. It enables other users to run "prog" without any modifications in PATH. Without links you can also change global PATH settings, but I'd rather avoid this. In both cases "prog" has to use _current_ not _executable_ dir to avoid mixing files of different users. Wojtek Florek _______________________________________________ Prime mailing list [email protected] http://hogranch.com/mailman/listinfo/prime
