Bug#391392: openoffice.org-common: soffice script does not handle multiple or space-containing Moz profiles
On Fri, Oct 06, 2006 at 02:59:06PM +0200, Rene Engelhard wrote:
> Am Freitag, 6. Oktober 2006 14:09 schrieb Jamm!n Wheeler:
> > The /usr/lib/openoffice/program/soffice script produces errors from
> > dirname(1) when the user's Mozilla or Firefox profile directory name
> > contains spaces. Also, when the user has more than one profile,
>
> Huh? How do you get one with spaces? I don't see any path in the list of checked
> dirs which has spaces? and the subdirs of it don't have either, do they?
If you create a profile with a space in the profile name, then the subdir has
a space in its filename. Like this:
.mozilla/firefox/<random>.Foxyproxy test/
.mozilla/firefox/<random>.No Extensions/
If you look at the patch I sent, you should see why using this value
in the dirname call without quoting it is going to cause problems.
> > MOZILLA_CERTIFICATE_FOLDER was being set to a nonsensical value.
>
> Hmm. Under which circumstances does this happen for you?
> I don't see a problem here. Because: If a matching dir is
> found, the next loop iteration does nothing.
This is *after* $dir has been set. The `find` call returns multiple
values if you have multiple profile subdirs within $dir, each with their
own cert8.db. Hence why it's necessary to use `head` to ensure
that you only have one (somewhat arbitrarily chosen, but then this
whole code seems arbitrary to me).
> (See also below)
>
> > The attached patch rectifies both these problems.
>
> head -1 is broken. It is head -n 1. What is this for btw?
*researches*. Hm, ok, by "broken" you mean it works but it's not POSIX
compliant. Sorry, I never realised... The -<num> (or +<num>) syntax is
the only usage I have ever seen in 12 years as a sysadmin on many
flavours of unix. Never seen -n before. Good to know though, thanks.
> Does ~/.firefox for example has two cert8.dbs? Probably not.
>
> The only way I can see for multiple cert8.dbs (assuming every profile has
> only one) is when it searches ~/.mozilla. But it shouldn't reach there
> if you use Firefox
Well, I do and it does. My profiles are in
.mozilla/firefox/<random>.<profilename>
firefox package 1.5.dfsg+1.5.0.7-1
> I currently don't see a problem but it also might be I either am assuming something which is not
> true in all cases or I oversee something.
All you should need to do to reproduce this bug is run
firefox -ProfileManager
create a new profile (or two if you don't already have one)
then run soffice.
Ben
Reply to: