GTK programs don't open files with blanks anymore

0BADC0DE · 2024-06-18 13:57:10

It looks like something has happened somewhere.
Libreoffice and Audacity cannot be used to open files whose name contains blanks or require otherwise quoting escaping.
It this me or is this a new bug?

seth · 2024-06-18 17:31:05

Open "how"?
* File picker dialog? => xdg-portal issue?
* Open the file with some rmb menu from a file browser?

When did this start?
gtk and audacity haven't been updated in a month, the closest would have been a glib2 update ~1 week ago.

0BADC0DE · 2024-06-18 18:10:28

seth wrote:

Open "how"?
* File picker dialog? => xdg-portal issue

This one.

Last edited by 0BADC0DE (2024-06-18 18:10:43)

seth · 2024-06-18 18:13:20

Do you have (and which) and xdg-desktop-portal-impl installed/in use?
https://archlinux.org/packages/extra/x8 … op-portal/

Does it help to "export ADW_DISABLE_PORTAL=1" to the client?

0BADC0DE · 2024-06-18 18:41:24

seth wrote:

Do you have (and which) and xdg-desktop-portal-impl installed/in use?
https://archlinux.org/packages/extra/x8 … op-portal/

extra/xdg-desktop-portal 1.18.4-1 [0 B 2.18 MiB] [Installed]
extra/xdg-desktop-portal-kde 6.0.5-1 [0 B 1.34 MiB] [Installed] (plasma)

seth wrote:

Does it help to "export ADW_DISABLE_PORTAL=1" to the client?

It's getting little bit trickier to add a variable to the launcher.

Could not save properties due to insufficient write access to:
‘/home/user/.local/share/applications/libreoffice-writer.desktop’.

Let me try something here!

[UPDATE]
It doesn't work from CLI either:

$ libreoffice --writer Untitled\ 1.odt 
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx

Throws the same "/home/user/Untitled does not exist." and " /home/user/1.odt does not exist." .
But I can start Libreoffice and then open the file.

Last edited by 0BADC0DE (2024-06-18 18:46:02)

seth · 2024-06-18 18:51:26

Ok, but that
a) isn't the file dialog
b) "I can start Libreoffice and then open the file" sounds like the file picker in LO is actually NOT affected
c) is pot. libreoffice specific, and libreoffice is a shell script

Try

file /usr/bin/lowriter # cause i don't have LO installed, maybe that's another script
/usr/bin/lowriter 'Untitled 1.odt'

0BADC0DE · 2024-06-18 19:34:08

I think it is not the portal, but likely the script itself (IMHO).
If I execute:

$ libreoffice --writer Untitled\ 1.odt

(please, note the "\" that bash injected via file completion), the actual "thing" to be executed in the shell reads:

exec $RRCHECK $VALGRINDCHECK $STRACECHECK "$sd_prog/oosplash" "$@"

(please note the trailing "$@" which should expand to three split words (w/o quotes): '--writer', 'Untitled' and '1.odt' and explain the problem!)

According to the friendly manual, this should not be like that!
But also "$*" is not ok as it triggers:

Error in option: --writer Untitled 1.odt

So I think the script has been "updated" with this regression.
Or maybe even the command line option processing schema by oosplash (the actual binary).

WDYT?

seth · 2024-06-18 19:59:13

Add "echo ${#@}" to see how many fields there are.
You're using bash all the way?
Is only the whitespace escaping backslash affected or also quoted filenames?

0BADC0DE · 2024-06-19 11:21:19

I added this line to the "soffice" script just before the actual exec in the last line:

echo "${#@} '$@'"

If I run:

libreoffice --writer Untitled\ 1.odt

3 '--writer Untitled 1.odt'
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx

I get the error and 3 arguments, as reported earlier. But if I run:

$ /usr/lib/libreoffice/program/soffice --writer ./Untitled\ 1.odt 
2 '--writer ./Untitled 1.odt'
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
QGuiApplication::setDesktopFileName: the specified desktop file name ends with .desktop. For compatibility reasons, the .desktop suffix will be removed. Please specify a desktop file name without .desktop suffix

I don't get the error. Of course, in the latter case the blank escaping happens at the CLI and not in the script-to-script call, so I only get 2 arguments.
I would say it's a script bug.

Last edited by 0BADC0DE (2024-06-19 11:25:05)

seth · 2024-06-19 15:39:12

file /usr/bin/libreoffice

If that's a script, please post it.

0BADC0DE · 2024-06-20 07:01:11

seth wrote:

file /usr/bin/libreoffice
If that's a script, please post it.

As I explained earlier, for some historical reason it's actually 2 scripts/
This is the "main" script, aka "/usr/bin/libreoffice".
And this is the "second stage" script, aka "/usr/lib/libreoffice/program/soffice".
The actual binalry launch is done at the very last line of the latter and that's where the CLI arguments are got wrong as far as quoting.

seth · 2024-06-20 07:04:29

Those are the same files, sure /usr/bin/libreoffice isn't just a symlink to /usr/lib/libreoffice/program/soffice ?
(I'm less than eager to install an office suite to figure that)

0BADC0DE · 2024-06-20 07:15:37

seth wrote:

Those are the same files, sure /usr/bin/libreoffice isn't just a symlink to /usr/lib/libreoffice/program/soffice ?
(I'm less than eager to install an office suite to figure that)

The former is a symlink to the latter. My bad I didn't check.

Last edited by 0BADC0DE (2024-06-20 07:49:04)

seth · 2024-06-20 14:16:56

SO the only real difference in #9 is the script invocation - what if you call libreoffice by its absolute path?

/usr/bin/libreoffice --writer Untitled\ 1.odt
/usr/bin/libreoffice --writer ./Untitled\ 1.odt
/usr/bin/libreoffice --writer 'Untitled 1.odt'

?

0BADC0DE · 2024-06-20 14:32:05

seth wrote:

SO the only real difference in #9 is the script invocation - what if you call libreoffice by its absolute path?
/usr/bin/libreoffice --writer Untitled\ 1.odt
/usr/bin/libreoffice --writer ./Untitled\ 1.odt
/usr/bin/libreoffice --writer 'Untitled 1.odt'
?

Of course only the third option works. And it works also as

/usr/bin/libreoffice --writer "Untitled 1.odt"

Relative or absolute path is irrelevant: the problem is clearly the (un)quoting of any argument including a blank.

Last edited by 0BADC0DE (2024-06-20 14:33:17)

seth · 2024-06-20 15:00:08

https://bbs.archlinux.org/viewtopic.php … 8#p2178668

But if I run:

$ /usr/lib/libreoffice/program/soffice --writer ./Untitled\ 1.odt 
2 '--writer ./Untitled 1.odt'
…

I don't get the error.

How is that functionally different from running

/usr/bin/libreoffice --writer Untitled\ 1.odt

if /usr/bin/libreoffice is a symlink to /usr/lib/libreoffice/program/soffice ?

0BADC0DE · 2024-11-08 16:29:44

How to (easily) reproduce:
1. Open dolphin (or another file navigator)
2. Reach a directory with a LibreOffice file
3. Rename it to include at least one blank
4. Doubleclick on it

Expected result:
The LibreOffice file gets (trivially) opened by LibreOffice

Actual result:
LibreOffice complains multiple times it cannot access some files (plural) whose names come from the original file name splitted by the blank(s).

It happens:
Always.

Hints:
It is KDE/Plasma!

seth · 2024-11-08 21:45:21

That doesn't address the conflicting information given previously.

You stated across various posts:
1. "/usr/lib/libreoffice/program/soffice --writer ./Untitled\ 1.odt" works
2. "/usr/bin/libreoffice --writer ./Untitled\ 1.odt" does not work
3. /usr/bin/libreoffice is a symlink to /usr/lib/libreoffice/program/soffice

Is this still true?

stat /usr/bin/libreoffice
type -a libreoffice

Arch Linux

#1 2024-06-18 13:57:10

GTK programs don't open files with blanks anymore

#2 2024-06-18 17:31:05

Re: GTK programs don't open files with blanks anymore

#3 2024-06-18 18:10:28

Re: GTK programs don't open files with blanks anymore

#4 2024-06-18 18:13:20

Re: GTK programs don't open files with blanks anymore

#5 2024-06-18 18:41:24

Re: GTK programs don't open files with blanks anymore

#6 2024-06-18 18:51:26

Re: GTK programs don't open files with blanks anymore

#7 2024-06-18 19:34:08

Re: GTK programs don't open files with blanks anymore

#8 2024-06-18 19:59:13

Re: GTK programs don't open files with blanks anymore

#9 2024-06-19 11:21:19

Re: GTK programs don't open files with blanks anymore

#10 2024-06-19 15:39:12

Re: GTK programs don't open files with blanks anymore

#11 2024-06-20 07:01:11

Re: GTK programs don't open files with blanks anymore

#12 2024-06-20 07:04:29

Re: GTK programs don't open files with blanks anymore

#13 2024-06-20 07:15:37

Re: GTK programs don't open files with blanks anymore

#14 2024-06-20 14:16:56

Re: GTK programs don't open files with blanks anymore

#15 2024-06-20 14:32:05

Re: GTK programs don't open files with blanks anymore

#16 2024-06-20 15:00:08

Re: GTK programs don't open files with blanks anymore

#17 2024-11-08 16:29:44

Re: GTK programs don't open files with blanks anymore

#18 2024-11-08 21:45:21

Re: GTK programs don't open files with blanks anymore

Board footer