On close inspection the soffice script is not the real culprit because
although it always backgrounds the binary it also has "wait $!" right
afterward so the critical behaviour occurs at a deeper level when the
binary forks various layers of itself.

I'd like to just add a comment here that it should not be a guessing
game to figure out whether a program will detach itself or not. Consider
this file:

     /usr/lib/mime/packages/openoffice.org-writer

The contents get into /etc/mailcap when /usr/sbin/update-mime runs, and
hence various programs (for example the "mutt" email client) are
instructed how they should execute OpenOffice in order to display a
file. The current setting is:

     soffice -no-oosplash -writer '%s'

Sadly, this will detach if OpenOffice is running somewhere on the
desktop, but it will not detach should this be the first instance of
OpenOffice. In other words, arbitrarily it may or may not detach for
reasons unrelated to (and unknowable to) the program that tries to
invoke the MIME entry. By the way, the "-no-oosplash" option still shows
a splash screen (go figure), the open office wiki does not document the
"-no-oosplash" option either (maybe it is not a supported option).

What should happen is that certain command line options force it to
NEVER detach, strictly if those options are present. In every other
situation it should ALWAYS detach because OpenOffice is primarily an
interactive desktop application. The behaviour of a command should never
depend on factors beyond the options of that command, otherwise everyone
is back into guessing games.

For what it's worth, the /usr/bin/oowriter script does appear to always
detach as far as I can check. Would be nice if the OpenOffice website
would make more of an effort to document the supported command line
options so people working with this had some idea of what is supposed to
happen.

-- 
[ooo-build] cannot start OpenOffice.org with xvfb-run
https://bugs.launchpad.net/bugs/242844
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to