On Wed, Jul 23, 2014 at 4:08 PM, Andrea Pescetti <pesce...@apache.org> wrote: > > On 23/07/2014 JD wrote: >> >> in /usr/bin, I have: >> $ ls -l /usr/bin/*office* >> lrwxrwxrwx 1 root jd 32 Jul 23 12:18 /usr/bin/ooffice -> >> /opt/openoffice4/program/soffice >> > > This is a symlink you put there, right?
YES. Reason is that libreoffice has already stolen soffice in /usr/bin, and believe it or not, it has also stolen ooffice. Both of which link to libreoffice. So I broke the link /usr/bin/oofice -> libreoffice and made it link to /opt/openoffice4/program/soffice. > > > >> However, if I execute /opt/openoffice4/program/soffice from the terminal, >> openoffice runs. > > > The best way to launch OpenOffice is to make a shell alias. If this is unacceptable to you, make a one-line shell script that in turn launches > /opt/openoffice4/program/soffice and it will work too. I have already created the shell alias. But I was hoping to launch it from gui because some attachments I get are MS doc types, and want to automagically open them with /bin/ooffice which at this point does no look possible. > > >> So, soffice script takes arg0 and blithely assumes that <arg0>.bin exists, >> and tries to exec it. >> Why should a script assume that? It is at least dangerous, especially if >> executed by a superuser!! > > > This is how it works indeed: sd_binary=`basename "$0"`.bin > I haven't investigated it further, but if the .bin file needs to be in the (non user-writable) "program" directory too this could be a mitigating factor. Development-related matters are discussed on the dev list http://openoffice.apache.org/mailing-lists.html where you can raise the issue or propose patches to the shell script. My past experience with dev lists have not proven fruitful, and thus I hesitated to subscribe to the dev list.
