> "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`.
Right on the mark, Mr. Celti,
I discovered this mere minutes before your mail.
August 2, 2019 11:10 AM, "Eli Schwartz via arch-general"
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
> 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
>
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
On 8/2/19 1:48 PM, Chris Billington via arch-general wrote:
... I do
not understand the escape sequences \303\251 ...
They're octal:
303 (octal) = 011 000 011 (binary) = 0 1100 0011 (binary) = c3 (hex)
251 (octal) = 010 101 001 (binary) = 0 1010 1001 (binary) = a9 (hex)
HTH,
Dan
> 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
> 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:
>
That's interesting. If I run:
touch Proc$'\303\251'dures
and then ls, I get
> 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,
> 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
> 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
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
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
On 8/2/19 12:23 PM, John Z. wrote:
...
>> I don't have a direct answer, but check the version(s) of LibreOffice,
There might also be a difference between libreoffice-fresh and
libreoffice-still which is quite a bit behind fresh.
> 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
Hi,
both MUAs Evolution and Claws are broken on my machine. I tried to at
least work around the Evolution issue, but this was a naive
miscalculation.
I ensured that icu 64 is available for other apps and that ico 63 is
available to build and run evolution and that the sonames are linked
against
On 8/2/19 8:59 AM, John Z. wrote:
> 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.
Good
16 matches
Mail list logo
