I have moved my Leap 42.2 installation to use the KDE Framework 5 applications but have found that the file associations for the KF5 applications do not work with spaces in the target file name.
Example okular - the file association is:
sh -c " -e /opt/kf5/share/env/kf5.sh ]] && . /opt/kf5/share/env/kf5.sh; /opt/kf5/bin/okular %U"
So when the application is run it may be invoked with:
/opt/kf5/bin/okular file with spaces.pdf
This will fail because it looks for three files:
file
with
spaces.pdf
The solution is to change the file association to:
sh -c " -e /opt/kf5/share/env/kf5.sh ]] && . /opt/kf5/share/env/kf5.sh; /opt/kf5/bin/okular “%U”"
Now all I have to do is change all the other file associations but first I will have to find them!
This could take some time.
im slightly confused, file associations appear to work perfectly on TW. for those of us less versed in the obscurifications of bash could you explain the problem (what your trying to solve)? AFAIK “/opt/kf5/bin/okular file with spaces.pdf” should indeed fail by design?
Hi ndc33.
The standard file association for okular as found in System Settings -> Applications -> File Associations -> Find pdf is
okular %U %i -caption %c
and for the document viewer evince is
evince %U
where AFAIK the %U inserts the file name but something in the KDE application launch ensures that it is “quoted” so the spaces will be treated as part of the one file name.
When the KF5 version is invoked, something in the structure looses this implied “quoting” of the file name. Maybe because the whole command is “quoted”. So to resolve this the “quotation marks” have to be inserted explicitly.
As for the obfuscation of bash I have to agree. The syntax is Byzantine and there are so many ways of doing everything. Here we have:
sh = invoke the default version of the shell command (bash)
-c = the following is the command for the invoked shell
expression ]] = test this condition
-e /opt/kf5/share/env/kf5.sh = does the file exist?
&& = if the result is true then execute the following command
. /opt/kf5/share/env/kf5.sh = the command is to read and execute the contents of the file (space between . and filename)
; = having done that now do this…
/opt/kf5/bin/okular %U = the command okular with the file name but it would appear in this case unquoted.
So the change to
/opt/kf5/bin/okular “%U” puts the file name inside quotes and passes it on as it is with spaces and all.
For clarification: You are apparently using the KF5 packages from my repo, home:wolfi323:branches:KDE:Frameworks5.
Those cryptic Exec lines are a trick to make those applications work on other desktops than Plasma5. The packages install the files to /opt/kf5/ instead of /usr/ to achieve coinstallability with KDE4, some changes to the environment need to be done so that the applications actually find their files and libraries there.
I haven’t noticed this problem with spaces myself so far (apparently I don’t have any files with spaces in the name… ), but thanks for reporting it.
I will have a look at trying to fix it. Unfortunately it will not be so straight forward as to just add the quotes to the Exec lines, because I generate those automatically based on the original one…
%U A list of URLs. Each URL is passed as a separate argument to the executable program. Local files may either be passed as file: URLs or as file path.
Same as %F:
%F A list of files. Use for apps that can open several local files at once. Each file is passed as a separate argument to the executable program.
%u or %f mean one single file.
So quoting %U (and %F) is definitely wrong.
Anyway, I will have a look at this and try to fix it.
In the worst case I probably could just remove that “hack” completely (I do build the applications with RPATH meanwhile, so they should at least find the libs in /opt/kf5/lib/ and start…)
FTR, the specs also say this:
Field codes must not be used inside a quoted argument, the result of field code expansion inside a quoted argument is undefined.
I want to test it with other desktops first though (mainly GNOME and IceWM, which I have installed).
It took me a while (and quite some experimentation) to find a construct that works in all of them even if /opt/kf5/share/env/kf5.sh does not exist, when I added that 2 years ago…
(it’s not necessary in Plasma5, as with my packages that script is run on login already)
Unfortunately, both do not even show the the application menu entry any more if I do that change.
And now I remember that that was exactly the reason why I used “sh” in the first place…
The specs say this:
The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. The executable program can either be specified with its full path or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment. The name or path of the executable program may not contain the equal sign (“=”). Arguments are separated by a space.
In short, this means the Exec line must look like this:
Exec=command arg1 arg2 ...
Apparently both IceWM and GNOME check whether “command” actually exists…
I have to think about this…
But as I wrote, I can probably remove that hack completely (only add the full path), it should not be really necessary any more.
Although there may be certain problems because the files in /opt/kf5/etc/ are not found (would mostly affect the “Get New …” functionality), and if applications run other commands (because /opt/kf5/ won’t be in the path). Though as I wrote that would only happen when run outside of Plasma5.
For the first problem, it should be possible to just move those files to /etc/ anyway, I think there wouldn’t be any conflicts as KDE4 used other locations.
I would have to check though.
and in plasma 5 all runs fine for the simple testing I have done.
Now for the big question…
Which other file associations should I change before they come up and bite me?
I have already found
/opt/kf5/bin/ark %U
.
I suppose that I could look in /opt/kf5/bin and alter all the application that I am likely to invoke from dolphin or other. Is there any other place to look?
As I wrote, for a Plasma5 session, that script is run on login anyway (otherwise Plasma5 wouldn’t even work).
I suppose that I could look in /opt/kf5/bin and alter all the application that I am likely to invoke from dolphin or other. Is there any other place to look?
You mean /opt/kf5/share/applications/ I suppose?
That should be the only place, currently all the modified .desktop files are installed to this location. (actually my modified suse_update_desktop_files script only adds that “hack” if the .desktop file is in fact in /opt/kf5/share/applications/…)
But, I decided to remove that for now, until I find a better solution.
It will take a while to rebuild all packages though…
PS: I do have another idea meanwhile:
I could modify the kf5.sh script to accept arguments and run them after setting up the environment.
The Exec lines would then be able to just look like this:
Exec=kf5.sh okular %U
In particular, I wouldn’t need to add any quotes myself, so the original problem that started this thread should be solved. And as kf5.sh would be a valid and existing command, it should work in other desktops too.
I’d just need to make sure that plasma5-session-envscript gets installed in that case…
Yes, it works great: with a single or multiple files, with or without spaces in the filenames, and also in GNOME and IceWM…
The only problem left is to make sure plasma5-session-envscript is installed, even if one only installs one single application.
I’m not really keen on adding a requirement to 200 packages…
But I’m sure I’ll find a solution for that too.
kf5.sh is in the package plasma5-session-envscript (actually that’s the only file in that package).
If the package is not installed, that script won’t be there in the first place…
That’s the only reason why I ran it conditionally in the first place.
As you have now enumerated the problem with I think I will handle the problems as I find them until you have a more permanent solution.
Your problem is fixed already, I currently do not call kf5.sh at all in the Exec lines any more.
The problem is just that rebuilding the packages is stuck currently it seems (OBS overloaded?)…
(160 packages have been rebuilt, but 235 still to go)
I disabled building completely now, so that at least the already rebuilt packages get published. Expect a (bigger) update soon.
), but thanks for reporting it.
