Set path for My Documents in Tools > Options > General Path to "/home/foo/" Paste the code below in basis and test. Return value is "/home/" sub testPathSubstitution msgbox GetItemsInstallPath("work") end sub Function GetItemsInstallPath (sItem$) as String Dim oPathSubst oPathSubst = createUnoService("com.sun.star.util.PathSubstitution") GetItemsInstallPath = oPathSubst.getSubstituteVariableValue(sItem) End Function Info 'http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Resolving_Path_Variables 'predefinedPathVariables : home, inst, prog, temp, user, work, path, lang, langid, vlang, instpath, progpath, userpath, insturl, progurl, userurl, workdirurl,baseinsturl, userdataurl, brandbaseurl
Was OK in 4.1.x > regression (didn't test for other variables)
(In reply to comment #1) > (didn't test for other variables) Did now with a random 6 items. Those work fine.
I tested it with 4.1.5 (openSUSE 64-bit), and for "work" I always got /home/timar/Documents regardless of the setting of the My Documents path. The "workdirurl" variable gave the correct path, but instead of /home/timar I got $(home). I also tested with 3.3 and in today's master, and I got the same results.
(In reply to comment #3) > ... thanks Andras, I will do some tests again later. I'm 100% sure that it behaves different now for me then in previous versions though.
(In reply to comment #3) > I tested it with 4.1.5 (openSUSE 64-bit), and for "work" I always got > /home/timar/Documents regardless of the setting of the My Documents path. > The "workdirurl" variable gave the correct path, but instead of /home/timar > I got $(home). *Version: 4.1.0.0.beta1 Build ID: 3a2c2d2417101e45fe07cfd8358acf2204a98f3 <home>/foo $(work) *Version: 4.1.5.3 Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24 <home>/foo $(work) *Version: 4.2.0.0.alpha1 Build ID: c2b9ad37f8a8de9c7dbdd76c86aecf6388107056 <home> empty *LfC Versie: 4.2-8 Build ID: 84584cc237b2eb93f7684d8fcd063bb37e87b5fb <home> empty *Version: 4.4.0.0.alpha0+ Build ID: b6da6a887a0417be02e123a6d19837123e58b94f TinderBox: Linux-rpm_deb-x86@45-TDF <home> empty So if that's different for you, it might/must be due to the Linux version or 32 vs 64 bits?
Looking at history in opengrok, I guess this is related http://cgit.freedesktop.org/libreoffice/core/commit/?id=56211a166ab25d80de84c2cccce22be15a9be051 @sbergman: FYI, no urgency for me, AFAICS now..
Cor, not sure if any of this makes a difference, but * what is your HOME environment variable? * are you really talking about /home/foo or about $HOME/foo (assuming they're different) * does that foo directory exist, what read/write/execute rights do you have on it?
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c6da8e49a96513eda73656f3f6212f980a74b51 Related fdo#77813: $(workdirurl) was always empty The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
the commit from comment 8 should address the empty $(workdirurl) values starting with LO 4.2 as reported in comment 5
Note that there always (at least dating back to OOo times) have been two different though related configuration items: (1) /org.openoffice.Office.Paths/Paths/['Work'] is a set element of type org.openoffice.Office.Paths:NamedPath, which, among other things, has a string property "WritePath" (2) /org.openoffice.Office.Paths/Variables/Work is a string property documented as "Expanded value of "$work". Must be a valid URL." At least on current master, (1) is the value reported by $(workdirurl) and is the value that is changed when you edit the Options' "LibreOffice - Paths - My Documents" entry, while (2) is the value reported by $(work). I do not know whether that confusing state of things is by design or by mistake, but, quite frankly, the relevant code is rather crap.
Hi Stephan, (In reply to comment #7) > Cor, not sure if any of this makes a difference, but > > * what is your HOME environment variable? /home/cono > * are you really talking about /home/foo or about $HOME/foo (assuming > they're different) the first > * does that foo directory exist, what read/write/execute rights do you have > on it? Yes, it does exist. I set it with Tools > Options .. Looking at you later comments: I think that will do it. Thanks! (And indeed confusing that two related /Variables/Work and /Paths/['Work'] ... )
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=095107f266fa376ea1b8fe4cf263277230f8da52&h=libreoffice-4-2 Related fdo#77813: $(workdirurl) was always empty It will be available in LibreOffice 4.2.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fa15216b2ffc70304d6bbc0f37e9c5b8cf4cff56&h=libreoffice-4-3 Related fdo#77813: $(workdirurl) was always empty It will be available in LibreOffice 4.3.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cor: following last comments of this bugtracker, may we close this one?
(In reply to Julien Nabet from comment #14) > Cor: following last comments of this bugtracker, may we close this one? Will need a quite moment to check all. Later..
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.