On Tuesday 10 July 2007 18:42, Wojciech Florek wrote: > > > > $ 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.
Umm. In actuality system utility binaries are _not_ in /usr/bin, they're in /usr/sbin unless they're needed in system maintainance mode in which case look in /sbin (the separation is done to make the file system which _has_ to be mounted as small as possible) /bin and /usr/bin as opposed to /sbin and /usr/sbin are for utilities likely to be used by all users. acroread would be a non-linux program so (assuming all users are to be able to exec it) it should be in /usr/local/bin If the Adobe installer wants to create its own directory tree it should have linked /usr/local/bin/acroread to /usr/local/Adobe/Acrobat7.0/bin/acroread > > 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. Sounds the sensible thing to me. Especially as many versions of linux already have ~/bin in the path; mine puts at at the beginning of the string! (Don't forget that ~ is a synonym for the home directory of the current user) > If "prog" has to be available to other users A recipe for cache-thrashing hell in the case of mprime > > In both cases "prog" has to use _current_ not _executable_ dir to avoid > mixing files of different users. > Precisely. Where the application can (sensibly) be used by more than one user and has files it needs to share between them, the sensible thing to do is to create a new environmental variable to point to the shared data directory. Regards Brian Beesley _______________________________________________ Prime mailing list [email protected] http://hogranch.com/mailman/listinfo/prime
