Good jump on the research.

I try to do what I can, before asking other people to spend their time on me :-)

I don't have a direct answer, but check the version(s) of LibreOffice, Dropbox, and possibly some of the other packages you've already mentioed. Perhaps your issue is something that's been fixed by a newer package in Ubuntu and not yet fixed in the corresponding package in Arch (or something that's been broken by a newer package in Arch and yet merged into Ubuntu). Maybe a release note or a patch will jump out at you.

That is a solid idea! I'll see if maybe I can find a version mismatch and downgrade accordingly. I already checked Libreoffice's bugtracker for this (which would indicate there's a patch incoming), but haven't found any entries, so I'll file one.

Thank you.

There might also be a difference between libreoffice-fresh and libreoffice-still which is quite a bit behind fresh.

Hi Gene, also a good idea, I wasn't even aware of the `libreoffice-still` package. I tried replacing `libreoffice-fresh` with it, and I still get the same error, although with slightly different looking dialog :-(

Could you verify that the encoding of the filepath is, in fact, UTF8? Filepaths in linux are free to be arbitrary bytes despite the locale settings. Most tools don't care, though I would expect the filepath to display incorrectly in the terminal and file browser if it were not UTF8. So it is probably a long shot but perhaps worth checking.

The following Python script, run in the directory containing the file/directory containing the french character should tell you if it it valid UTF8:

import os for item in os.listdir(b'.'): try: item.decode('utf8') except UnicodeDecodeError: print(item, "is not valid UTF8") raise

On Fri, Aug 2, 2019 at 12:48 PM Eli Schwartz via arch-general < arch-general@archlinux.org> wrote:

On 8/2/19 8:59 AM, John Z. wrote:

...

Hi everyone, there's a document on Dropbox, that has unicode character in its path (french character). Trying to open this document with libre office (Plasma is running) fails with 'file not found', and the path shown with error clearly presents the path with that unicode character replaced by '??'

What I tried:
* copy the document in a path where there's no unicode - it opens
* copy the document using shell - it works
* copy the document using Dolphin (from Plasma) - it works
* check $LANG - its set to `en_CA.UTF8`
* search for 'libreoffice unicode path', 'archlinux unicode path'
  and plethora of similar search terms - not much came through

This makes me think the issue is actually with LibreOffice, but the
reason I ask here, and not in their forum, is that on another
computer running Ubuntu - this works without fail, so I'm fairly
certain the issue is in some local configuration.

Could anyone shed some light on this, please, or at least point me
in some direction where I could look?

Can you determine some steps that exactly reproduce the problem? Assuming that the problem should manifest when opening the file using /usr/bin/loffice /path/to/file, I tried creating a test file and opening it, and it worked:

$ mkdir -p '/tmp/unicode paths are 💩/' $ touch '/tmp/unicode paths are 💩/testfile.txt' $ loffice '/tmp/unicode paths are 💩/testfile.txt' $

I could successfully edit this file in libreoffice, save content, or reopen it. Tested with LANG=en_US.UTF-8 and the libreoffice-fresh package

-- Eli Schwartz Bug Wrangler and Trusted User

On 8/2/19 1:24 PM, John Z. wrote:

...

Could you verify that the encoding of the filepath is, in fact, UTF8? Filepaths in linux are free to be arbitrary bytes despite the locale settings. Most tools don't care, though I would expect the filepath to display incorrectly in the terminal and file browser if it were not UTF8. So it is probably a long shot but perhaps worth checking.

Hi, thank you for the suggestion. I tried running your script, and all filenames are decoded correctly, no exception was thrown (I also tried without try/except just in case something else gets thrown)

However, you might be onto something here because, interestingly enough: while BASH prompt and autocompletition feature both decode the character correctly, `ls` does not and outputs a sequence of escape codes:

Proc'$'\303\251''dures

instead of

Procedures (where first 'e' is the unicode char, and has french accent)

The ls command will by default escape the character into its numeric code if it thinks the character is invalid in your locale. I can get ls to print the same thing as you (using shell-escaped $'\303\251') *iff* I first export LC_ALL=C (which is not a UTF-8 locale and therefore cannot print unicode characters).

This indicates something is wrong with your locale, because at the very least, your shell cannot parse the character correctly -- maybe neither can libreoffice.

August 2, 2019 11:10 AM, "Eli Schwartz via arch-general" arch-general@archlinux.org wrote:

The ls command will by default escape the character into its numeric code if it thinks the character is invalid in your locale. I can get ls to print the same thing as you (using shell-escaped $'\303\251') *iff* I first export LC_ALL=C (which is not a UTF-8 locale and therefore cannot print unicode characters).

This indicates something is wrong with your locale, because at the very least, your shell cannot parse the character correctly -- maybe neither can libreoffice.

"I forgot to generate the locales" will cause this issue. Try running `localedef --list-archive` and checking that en_CA.UTF-8 actually exists. If not, uncomment it in /etc/locale.gen and run `sudo locale-gen`.

~Celti

Can you determine some steps that exactly reproduce the problem? Assuming that the problem should manifest when opening the file using /usr/bin/loffice /path/to/file, I tried creating a test file and opening it, and it worked:

Hi Eli, good idea, I tried following your sequence as well.

I created a directory using `mkdir`, then launched libre office and tried to save a file in it. Interesting thing happens:, it actually creates a directory named 'Proc?dures' instead of the original 'Procédures' directory, and saves it in there. I repeated the test twice, because the first time around, I was puzzled enough that I wasn't sure I actually saved the file.

Furthermore, I copied the file using console into the 'Procédures', then opened it using libreoffice, and it opened the one in 'Proc?dures' - I know because I updated the file and saved it, and the latter one was updated.

The only difference between us is that I'm using `libreoffice` launcher command, and you seem to have `loffice`? The package is also libreoffice-fresh, package version 6.2.5-1, and `libreoffice --version` 6.2.5.2 2@(build: 2) The --version in ubuntu, that works, is 6.0.7.3

P.S. I am unsure how well Unicode fares in mailing lists, so I apologize if there are weird escape sequences in there. I just composed it with vim.

What happens if you run the following?

$ echo $'\303\251'

I get the character printing correctly.

Same here, it prints out fine. Terminal is Konsole. I tried touching new file with é, and ls again prints the escape sequence, however - trying to `cat` the file by hitting Tab to get autocompletition list, it prints it correctly there.

I am not entirely sure how to check for locale issues? I know there's an extensive page in arch wiki which I checked, but I don't think any of Troubleshooting issues applies.

I tried `localectl status` and, I dunno if this is normal, but it prints different locale than the one set in $LANG.

> echo $LANG en_CA.UTF-8

> localectl status System Locale: LANG=en_US.UTF-8 VC Keymap: n/a X11 layout: n/a

Changing keyboard layouts doesn't change the output of `localectl status`

A good command to use for these situations is locale(1). Note, the double quotes in the output are significant, as the fine man page explains.

Hi Ralph, thanks for the tip! I wasn't aware of this command previously, and I'm reading through the man right now.