Brian Beesley 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 > 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 > Or, at the very least, lead to no end of confusion. (I remember struggling > mightily with the directory structure on a Solaris system where some idiot > had tried to make life easier for him/herself by linking a directory to one > of its own leaves instead of modifying $PATH...) I wouldn't do it. > I agree with John (even though I know it isn't actually _necessary_ to copy > the binary). Mike, why bother to use a soft link (or even a hard one) when > you can simply place one copy of the binary somewhere on the path? The topic of discussion, I thought, was storing data files in the same directory as the executable. This is, in the general opinion of UNIX like OS admins I think, generally a bad idea. It's better to have one copy of the executable somewhere, and having config files per user. For example, suppose we have a package of executables named Package, with executables Prog1, Prog2, and Prog3. It's generally considered good practice to create /usr/local/Package/Version/bin/Prog1, /usr/local/Package/Version/bin/Prog2, and /usr/local/Package/Version/bin/Prog3, then put soft links in /usr/local/bin/Prog1, /usr/local/bin/Prog2, and /usr/local/bin/Prog3. That way, if some user needs an older package, all that has to be done is to place some soft links into his path which point to the older versions. Also, should some serious defect be discovered in a newer release, it can be backed out and the old stuff reinstalled by the sys admin simply changing a few links in /usr/local/bin. Any system wide config files get put into /usr/local/Package/Version/<package-specific-directory-and-files>. The user specific configuration would normally be stored in $HOME/.packagerc or, if it was significant, $HOME/.package/<package- specific-directory-and-files>. However, if one insists on storing the data with the executables, one does not need hundreds of copies of the executable just because there are hundreds of users. Placing a soft link into $HOME/bin or elesewhere in their path would do the trick. For more information on recommendations on where to store stuff, you might see http://www.pathname.com/fhs/ where some people have proposed a Standard path naming convention, which is pretty much taking over in the Linux distro world. It is based on UNIX like OS general practice. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} Oppose globalization and One World Governments like the UN. This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! _______________________________________________ Prime mailing list [email protected] http://hogranch.com/mailman/listinfo/prime
