Bug 130080 - Cant export to folder with Umlaut (ä/ü/ö) in folder name
Summary: Cant export to folder with Umlaut (ä/ü/ö) in folder name
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.4.0.1 rc
Hardware: All All
: medium normal
Assignee: Michael Weghorn
URL:
Whiteboard: target:7.0.0 target:6.4.1 target:6.3.5
Keywords:
: 126812 129736 129770 130726 130791 (view as bug list)
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2020-01-19 14:48 UTC by Axel Braun
Modified: 2020-02-24 12:12 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Axel Braun 2020-01-19 14:48:16 UTC
I have a file that is stored in a folder with an Umlaut in the name - and the file itself contains an Umlaut. I can open and save the file (so there is no relation to bug #126812 )

When I want to export the document to PDF the error message pops up that 'Der angegebene Ordner existiert nicht oder ist nicht lesbar.' (The selected forlder does not exist or is not readable).
This message pops up three times before the file-save dialog opens. Attempts to save the file in the folder with Umlauf fails with the same message. Saving to a different folder works.

Version: 6.4.0.1
Build-ID: 40(Build:1)
CPU-Threads: 4; BS: Linux 5.4; UI-Render: Standard; VCL: kf5; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded
openSUSE Tumbleweed
Comment 1 Xisco Faulí 2020-01-20 19:00:44 UTC
I can't reproduce it in

Version: 6.5.0.0.alpha0+
Build ID: fc1f85127968d1c2e0a53dace51bf8a78f9e6ca5
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

@Michael, do you reproduce it on your end ?
Comment 2 Michael Weghorn 2020-01-21 14:39:30 UTC
I cannot reproduce on current Debian testing with

Version: 6.5.0.0.alpha0+
Build ID: fc1f85127968d1c2e0a53dace51bf8a78f9e6ca5
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

This sounds similar to tdf#129736 (which I can't reproduce either).


Some questions that might help to narrow down the issue:

1) Can you paste the output of the command "locale"?

2) Does anythingchange if start libreoffice from command line with LC_ALL=C.UTF-8 set, like (replace '/path/to/' with the actual path):

    LC_ALL=C.UTF-8 /path/to/soffice

3) Does "Save as" (and saving under a different name in the same folder) work for the file?
Comment 3 erz96cxw 2020-01-21 17:10:22 UTC
Version: 6.4.0.1
Build ID: 40(Build:1)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

I have the same issue, so adding my observations here. With me it applies to every time the file picker is used (Open, Save, Export).

Output of locale:
LANG=en_GB.UTF-8
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=


Changing LC_ALL to "en_GB.UTF-8" fixes the issue. But since LC_ALL is the global override, I wonder if the VCL falls back incorrectly to ASCII if null is returned? Shouldn't fallback be to LANG first?
Comment 4 Axel Braun 2020-01-21 18:48:21 UTC
(In reply to Michael Weghorn from comment #2)

Y Some questions that might help to narrow down the issue:
> 
> 1) Can you paste the output of the command "locale"?

docb@T520:~> locale
LANG=de_DE.UTF-8
LC_CTYPE=de_DE.UTF-8
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

> 2) Does anythingchange if start libreoffice from command line with
> LC_ALL=C.UTF-8 set, like (replace '/path/to/' with the actual path):
> 
>     LC_ALL=C.UTF-8 /path/to/soffice

Yes, the file selection dialog comes up as expected. I can save the file (with Umlaut) into a folder with Umlaut

> 3) Does "Save as" (and saving under a different name in the same folder)
> work for the file?

After the LC_ALL=C.UTF-8 command? Yes
Before? no
Comment 5 Michael Weghorn 2020-02-03 10:28:06 UTC
(In reply to erz96cxw from comment #3)
> Version: 6.4.0.1
> Build ID: 40(Build:1)
> CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
> Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
> Calc: threaded
> 
> I have the same issue, so adding my observations here. With me it applies to
> every time the file picker is used (Open, Save, Export).
> 
> Output of locale:
> LANG=en_GB.UTF-8
> LC_CTYPE=en_GB.UTF-8
> LC_NUMERIC="en_GB.UTF-8"
> LC_TIME="en_GB.UTF-8"
> LC_COLLATE="en_GB.UTF-8"
> LC_MONETARY="en_GB.UTF-8"
> LC_MESSAGES="en_GB.UTF-8"
> LC_PAPER="en_GB.UTF-8"
> LC_NAME="en_GB.UTF-8"
> LC_ADDRESS="en_GB.UTF-8"
> LC_TELEPHONE="en_GB.UTF-8"
> LC_MEASUREMENT="en_GB.UTF-8"
> LC_IDENTIFICATION="en_GB.UTF-8"
> LC_ALL=
> 
> 
> Changing LC_ALL to "en_GB.UTF-8" fixes the issue. But since LC_ALL is the
> global override, I wonder if the VCL falls back incorrectly to ASCII if null
> is returned? Shouldn't fallback be to LANG first?

That's interesting and somewhat unexpected. Given your locale settings, I agree that setting LC_ALL to "en_GB.UTF-8" should not make a difference, since all other locale-related vars already have that value.

Interestingly, it works just fine for me on Debian testing with the same locale settings:

$ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME=en_DK.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

so I'm still unable to reproduce the issue myself.


(In reply to Axel Braun from comment #4)
> > 3) Does "Save as" (and saving under a different name in the same folder)
> > work for the file?
> 
> After the LC_ALL=C.UTF-8 command? Yes
> Before? no

Does LC_ALL=de_DE.UTF-8 also work? (similar to what erz96cxw did in comment 3)
Comment 6 Michael Weghorn 2020-02-03 10:29:55 UTC
Another question: Do other KDE applications (like Kate) also have any issue when using "Save as" with a file located in the same directory?
Comment 7 erz96cxw 2020-02-03 14:08:45 UTC
Hi there,
Kate handles everything as expected without changing the locale. Is this perhaps some VCL/kf5 bug?

To confound matters I did some testing. I can assign total nonsense to LC_ALL and it still works. Folders can be opened as expected. Obviously no locale gets assigned:

:~> LC_ALL="nonsense"  libreoffice
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (nonsense)
/usr/bin/libreoffice: line 173: warning: setlocale: LC_ALL: cannot change locale (nonsense)
Fontconfig warning: ignoring nonsense: not a valid language tag


But if I just run libreoffice from the same command line (no LC_ALL assignment), it does not work. Is perhaps the locale setting bypassed altogether, defaulting to some non-unicode locale, and only when LC_ALL is passed along, the locale setting branch is invoked?

The "fix" does not work with any other locale parameter (e.g. LANG), it has to be LC_ALL.
Comment 8 Axel Braun 2020-02-03 16:38:08 UTC
(In reply to erz96cxw from comment #7)

> Kate handles everything as expected without changing the locale. Is this
> perhaps some VCL/kf5 bug?

Confrirmed regarding the handling of kate.

> To confound matters I did some testing. I can assign total nonsense to
> LC_ALL and it still works. Folders can be opened as expected. Obviously no
> locale gets assigned:
> 
> :~> LC_ALL="nonsense"  libreoffice
> /bin/sh: warning: setlocale: LC_ALL: cannot change locale (nonsense)
> /usr/bin/libreoffice: line 173: warning: setlocale: LC_ALL: cannot change
> locale (nonsense)
> Fontconfig warning: ignoring nonsense: not a valid language tag

Can't confirm this. I can open with the 'nonsense' locale, but not safe it:
Error saving the document The_document:
Object not accessible.
The object cannot be accessed
due to insufficient user rights.

(I doubt this as I'm the owner of the directory. must be a kind of secondary issue)
Comment 9 erz96cxw 2020-02-03 16:41:46 UTC
(In reply to Axel Braun from comment #8)
> (In reply to erz96cxw from comment #7)
> 
> > Kate handles everything as expected without changing the locale. Is this
> > perhaps some VCL/kf5 bug?
> 
> Confrirmed regarding the handling of kate.
> 
> > To confound matters I did some testing. I can assign total nonsense to
> > LC_ALL and it still works. Folders can be opened as expected. Obviously no
> > locale gets assigned:
> > 
> > :~> LC_ALL="nonsense"  libreoffice
> > /bin/sh: warning: setlocale: LC_ALL: cannot change locale (nonsense)
> > /usr/bin/libreoffice: line 173: warning: setlocale: LC_ALL: cannot change
> > locale (nonsense)
> > Fontconfig warning: ignoring nonsense: not a valid language tag
> 
> Can't confirm this. I can open with the 'nonsense' locale, but not safe it:
> Error saving the document The_document:
> Object not accessible.
> The object cannot be accessed
> due to insufficient user rights.
> 
> (I doubt this as I'm the owner of the directory. must be a kind of secondary
> issue)

Confirmed re "nonsense" locale. I can open folders with an Umlaut, unlike when starting with no locale at all. But trying to open a file comes up with an error message, characters seem to indicate that 8859-1 is default fallback in this case.
Comment 10 Michael Weghorn 2020-02-03 17:27:16 UTC
(In reply to erz96cxw from comment #7)
> Kate handles everything as expected without changing the locale. Is this
> perhaps some VCL/kf5 bug?

Sounds probably, but it's hard to say without being able to see and analyze the issue myself...

What Linux distros (and versions) and what versions of Qt and libkf5kiofilewidgets5 do you have?
Comment 11 Michael Weghorn 2020-02-03 17:30:58 UTC
And are you using the distro-provided LibreOffice or the packages downloaded from the LibreOffice website?
Comment 12 Axel Braun 2020-02-03 19:02:44 UTC
(In reply to Michael Weghorn from comment #11)
> And are you using the distro-provided LibreOffice or the packages downloaded
> from the LibreOffice website?

I have tried both, package from LO Website as well as from Distro (openSUSE Tumbleweed 20200128), qt 5.14.0
ibkf5kiofilewidgets5 seems to be part of libreoffice-qt5:

nformationen zu Paket libreoffice-qt5:
---------------------------------------
Repository         : openSUSE-Tumbleweed-Oss                     
Name               : libreoffice-qt5                             
Version            : 6.4.0.3-1.1                                 
Arch               : x86_64                                      
Anbieter           : openSUSE                                    
Installierte Größe : 742,6 KiB                                   
Installiert        : Ja                                          
Status             : aktuell                                     
Quellpaket         : libreoffice-6.4.0.3-1.1.src                 
Zusammenfassung    : Qt5/KDE Frameworks interface for LibreOffice
Comment 13 erz96cxw 2020-02-03 19:52:33 UTC
(In reply to Axel Braun from comment #12)
> (In reply to Michael Weghorn from comment #11)
> > And are you using the distro-provided LibreOffice or the packages downloaded
> > from the LibreOffice website?
> 

I am on OpenSUSE Tumbleweed as well, just using their repositories, haven't tried direct download
qt=5.14.0
> rpm -q --whatprovides /usr/lib64/libKF5KIOFileWidgets.so.5
kio-5.66.0-1.1.x86_64
Comment 14 Michael Weghorn 2020-02-04 12:26:55 UTC
I have set up a Tumbleweed VM and can reproduce there; will take a look.

SAL_USE_VCLPLUGIN=qt5 works, i.e. it seems specific to the Plasma-native Qt file dialog.
Comment 15 Michael Weghorn 2020-02-04 12:49:29 UTC
The problem is caused by the LibreOffice shell wrapper, which sets LC_ALL, like this:

    LO_SAVE_LC_ALL="$LC_ALL"
    LC_ALL=C
    export LC_ALL
    # ... (call some tools,...)
    # restore locale setting
    LC_ALL="$LO_SAVE_LC_ALL"

This sets LC_ALL to an empty string if not set previously and the Plasma-native file Qt file dialog seems to have problems with this.

The same problem can be seen when running e.g. kate with that env variable:

    LC_ALL= kate

And directly running 'soffice.bin' instead of the 'soffice' shell wrapper also works as expected.

The "locale" command behaves differently from what the kf5 libs seem to do here:

* explicit empty value is ignored

$ LC_ALL= locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME=en_DK.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

* setting a non-empty value makes that one take effect, even if invalid:

$ LC_ALL=abcd locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="abcd"
LC_NUMERIC="abcd"
LC_TIME="abcd"
LC_COLLATE="abcd"
LC_MONETARY="abcd"
LC_MESSAGES="abcd"
LC_PAPER="abcd"
LC_NAME="abcd"
LC_ADDRESS="abcd"
LC_TELEPHONE="abcd"
LC_MEASUREMENT="abcd"
LC_IDENTIFICATION="abcd"
LC_ALL=abcd

So I'd assume that kf5 libs should probably do the same?
(and probably have done so in the past, at least the LibreOffice wrapper seems to have been doing that for years already)
Comment 16 Michael Weghorn 2020-02-04 14:28:11 UTC
(In reply to Michael Weghorn from comment #15)
> [...]
> So I'd assume that kf5 libs should probably do the same?
> (and probably have done so in the past, at least the LibreOffice wrapper
> seems to have been doing that for years already)

I'm in contact with KDE developers, but it's not clear at once where that handling comes from. Easiest thing would probably be to adapt the LibreOffice wrapper to unset LC_ALL again in the end if it wasn't set at the beginning, but maybe we can still find out a bit more.
Comment 17 Michael Weghorn 2020-02-04 16:04:12 UTC
From IRC #kde-devel:

> [16:25] <frinring> michaelweghorn: just did some quick fprint debugging. seems the cause is that QTextCodec::codecForLocale() becomes US-ASCII is LC_ALL= is in the envirnment. lost track of the calls on the border to the icu lib, but seems the issue is over there
> ...
> [16:35] <michaelweghorn> frinring: thx! I'll take a look there to see whether I can rather quickly find more, but will otherwise probably go with adapting the libreoffice wrapper
> [16:36] <frinring> michaelweghorn: yes, that would be good in any case to deal with unfixed qt
> ...
> [16:47] <frinring> michaelweghorn: so, to summarize: Qt's text code when using libicu calls  ucnv_getDefaultName() from unicode/urename.h, which returns US-ASCII when LC_ALL is defined as emptyy string in the env. qt recently switched to libicu IIRC, so that's why it is popping up now
> ...
> [16:49] <frinring> to be tested with linking icuuc, #include <unicode/ucnv.h> and calling ucnv_getDefaultName() which returns const char*
> ...
> [16:52] <michaelweghorn> frinring: thanks for your analysis! Can I paste that to the LibreOffice bugzilla issue?
> ...
> [17:00] <frinring> michaelweghorn: sure. this should also affect other apps using libicu possibly, like chromium
Comment 18 Michael Weghorn 2020-02-04 17:14:57 UTC
(In reply to Michael Weghorn from comment #17)
> From IRC #kde-devel:
> ...
> > [16:49] <frinring> to be tested with linking icuuc, #include <unicode/ucnv.h> and calling ucnv_getDefaultName() which returns const char*

Indeed, the following test program using ICU compiled with 

    g++ test.cpp $(pkg-config --libs --cflags icu-uc icu-io)

and then called with LC_ALL="" prints "US-ASCII" on Tumbleweed (ICU at version 65.x) and KDE Neon dev edition (ICU at version 60.2), while it prints "UTF-8" on my Debian testing (ICU at version 63.2):


#include <unicode/ucnv.h>
#include <iostream>

int main() {
    std::cout << ucnv_getDefaultName();
}
Comment 19 Michael Weghorn 2020-02-05 08:34:18 UTC
With a Self-built ICU from current master (as of commit d6b88d49e3be7096baf3828776c2b482a8ed1780 ), the sample program from comment 18 also returns "UTF-8" on KDE neon dev edition, other than the system ICU:

Self-built ICU master:
> user@neondeveloper:~/development/git/icu/icu4c/source$ g++ -o icu-test -O0 -g -I/tmp/icu/include/ -L/tmp/icu/lib/ icu-test.cxx -licudata -licuuc
> user@neondeveloper:~/development/git/icu/icu4c/source$ LC_ALL="" ./icu-test 
> UTF-8

System ICU:
> user@neondeveloper:~/development/git/icu/icu4c/source$ g++ -o icu-test -O0 -g icu-test.cxx -licudata -licuuc
> user@neondeveloper:~/development/git/icu/icu4c/source$ LC_ALL="" ./icu-test 
> US-ASCII

(with LD_LIBRARY_PATH=/tmp/icu/lib , because I passed /tmp/icu as prefix to configure)

Might be related to different ICU configure options used by the distros (I passed none besides '--with-prefix=/tmp/icu'), differing versions (but see comment 18), or something else, but I'll stop investigating at this point for now and will adapt the LibreOffice shell wrapper (which makes sense anyway, also taking into account existing installations).
Comment 20 Michael Weghorn 2020-02-05 09:44:17 UTC
(In reply to Michael Weghorn from comment #19)
> [...] will adapt the LibreOffice shell wrapper (which makes sense
> anyway, also taking into account existing installations).

-> Patch pending at https://gerrit.libreoffice.org/c/core/+/88003
Comment 21 Michael Weghorn 2020-02-05 09:47:57 UTC
*** Bug 126812 has been marked as a duplicate of this bug. ***
Comment 22 erz96cxw 2020-02-05 10:36:18 UTC
(In reply to Michael Weghorn from comment #21)
> *** Bug 126812 has been marked as a duplicate of this bug. ***

(In reply to Michael Weghorn from comment #20)
> (In reply to Michael Weghorn from comment #19)
> > [...] will adapt the LibreOffice shell wrapper (which makes sense
> > anyway, also taking into account existing installations).
> 
> -> Patch pending at https://gerrit.libreoffice.org/c/core/+/88003

Tried your patch and can confirm that it is working as expected. Thanks for getting to the bottom of this!
Comment 23 Michael Weghorn 2020-02-05 12:03:31 UTC
*** Bug 129736 has been marked as a duplicate of this bug. ***
Comment 24 Commit Notification 2020-02-05 14:46:46 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/25649502e08a52087dea5e482d34a1d4150f0930

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 Michael Weghorn 2020-02-05 14:50:15 UTC
(In reply to erz96cxw from comment #22)
> Tried your patch and can confirm that it is working as expected. Thanks for
> getting to the bottom of this!

Thanks for testing!

Fixed on master branch now, backports for libreoffice-6-4 and -6-3 pending in Gerrit.
Comment 26 Axel Braun 2020-02-05 16:34:54 UTC
(In reply to Michael Weghorn from comment #25)

> Fixed on master branch now, backports for libreoffice-6-4 and -6-3 pending
> in Gerrit.

Thank you very much for your quick resolution of this issue. I will try the nightly next days.
Comment 27 Commit Notification 2020-02-06 09:14:28 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/d037d971b4f4f408c7a6b6c15a0c7e742f61d354

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 6.4.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 28 Commit Notification 2020-02-06 09:14:47 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/3c5eda2a18097547ac9597ccad7477e2aaa65f26

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 6.3.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 29 Commit Notification 2020-02-07 13:11:27 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-3-5":

https://git.libreoffice.org/core/commit/1253f7e8fa405ee39bb72dc24d02a09dc757aa58

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 6.3.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 30 Commit Notification 2020-02-07 13:11:42 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-6-4-1":

https://git.libreoffice.org/core/commit/48117f353c60de971089b793bbdd48f897cb62f0

tdf#130080 soffice.sh: Avoid exporting empty LC_ALL

It will be available in 6.4.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 31 Xisco Faulí 2020-02-17 12:46:30 UTC
*** Bug 130726 has been marked as a duplicate of this bug. ***
Comment 32 Michael Weghorn 2020-02-20 09:53:30 UTC
*** Bug 130791 has been marked as a duplicate of this bug. ***
Comment 33 David de Cos 2020-02-24 12:12:21 UTC
*** Bug 129770 has been marked as a duplicate of this bug. ***