http://bugzilla.opensuse.org/show_bug.cgi?id=1162882 Bug ID: 1162882 Summary: Qt apps cannot handle non-ASCII filesystem path if LC_ALL present as empty string in env (libicu-uc blame) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs@opensuse.org Reporter: kossebau@kde.org QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- libicu-uc's ucnv_getDefaultName() returns "US-ASCII" if LC_ALL is set explicitly to an empty string in the environment (compared to not being set at all). As effect e.g. all Qt-based code run where LC_ALL="" is part of the environment variables is not able to handle non-ASCII path in the filesystem. Example: run LC_ALL= kate or okteta, kwrite, etc. and try to load or save a file with non-ascii chars, like German umlauts äöü (ex: "ärger.txt"). Because Qt's QTextCodec::codecForLocale() used for decoding/encoding names from the filesystem is an instance of QIcuCodec (on openSUSE & friends) which queries the system default from libicu-uc by that very ucnv_getDefaultName(). That behaviour of libicu-uc is rather unexpected. And seems also not present on all Linux flavours, e.g. with some versions of Debian & Ubuntu LC_ALL="" was treated the same as not being set. All code I have seen elsewhere handling LC_ALL does not make a difference between being not set or being an empty string, but maps both to: not set. POSIX.1-2017 take on this seems this: "If the LC_ALL environment variable is defined and is not null, the value of LC_ALL shall be used." from https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html Some old commit to libicu once fixed things for Solaris only: https://github.com/unicode-org/icu/commit/a8b1972f9263f481d0c50db709f93da381... Not idea if that code patched there is the code responsible for what we see here, but the pattern (check for a != 0 && *a != \0) would be the same. To reproduce the issue, find a small sample program and build instructions in this comment: https://bugs.documentfoundation.org/show_bug.cgi?id=130080#c18 (that bug is about the wrapper script for starting libreoffice actually resulting in LC_ALL being set to an empty string, thus failing with the Qt/KF platform plugin to handle non-ascii filesystem names). Had no time to look into libicu myself, thus also no proposals what and how to fix/patch here exactly. -- You are receiving this mail because: You are on the CC list for the bug.