See also #5220, #4666, #3855, #711.

Since Steam already uses GLib, probably the easiest way to parse .desktop files correctly would be to parse Exec into a command and arguments with g_shell_parse_argv(), which is the same thing that's done to launch applications from the menus of GLib-based desktop environments like GNOME and XFCE.

If I try escaping characters in a file, i.e. Exec=/home/lat9nq/repos/yuzu/build/bin/./yuzu -g /home/lat9nq/ROMs/NX/Pok__mon\ Legends_\ Arceus\ v0\ \(01001F5010DFA000\).xci, Steam will reduce the arguments to -g /home/lat9nq/ROMs/NX/Pok__mon Legends_ Arceus v0 (01001F5010DFA000).xci which does not work (launching through Steam, the program receives the argument /home/lat9nq/ROMs/NX/Pok__mon).

If I add \" before and after the file name, it works in Steam (which reduces it to "/file/name" in LAUNCH OPTIONS) but is unusable on the host operating system (the application receives the string "/file/name").

Again like the original issue, simple double-quotes around the file name makes Steam ignore the arguments altogether.

The motivation behind this issue is yuzu-emu/yuzu/pull/6769

If I add \" before and after the file name, it works in Steam (which reduces it to "/file/name" in LAUNCH OPTIONS) but is unusable on the host operating system (the application receives the string "/file/name").

This suggests that Steam might be using the wrong syntax to parse the Exec line.

If/when someone with access to the proprietary parts of Steam looks into this, using GKeyFile followed by g_shell_parse_argv() would probably work better: that's how GLib-based desktop environments like GNOME and XFCE parse .desktop files, and Steam depends on GLib already, so it might as well use the same code.

Looking at the related issues mentioned in the first comment, I'm not sure that they are all fixed as their status suggests. I'm testing this with the 15 Aug 2022 build of Steam.

Here's one simple .desktop file:

$ cat /tmp/FooBar.desktop 
[Desktop Entry]
Type=Application
Name=FooBar
Exec="/home/deck/Desktop/FooBar.sh"

$ touch /tmp/addnonsteamgamefile
$ xdg-open steam://addnonsteamgame/%2Ftmp%2FFooBar.desktop

This results in a new entry in the games library with

Target: ""/home/deck/Desktop/FooBar.sh""
Start in: ""/home/deck/Desktop"

(note the that there is four double quotes in the first case and three in the second one)

Now, if the shell script contains a space then we would have this the Exec line in FooBar.desktop:

Exec="/home/deck/Desktop/Foo Bar.sh"

This results in:

Target: ""/home/deck/Desktop/Foo"
Start in: ""/home/deck/Desktop"

(again, look at the number of double quotes).

The launch options are empty in both cases.

https://steamcommunity.com/groups/SteamClientBeta/announcements says the new Steam beta on 2023-02-22 had "Fixes for quotes surrounding shortcut exe and paths", which might help this?

I just checked with the Feb 24 2023 build, and this is only partially solved.

Exec="/home/deck/Desktop/FooBar.sh"

This results in
Target: "/home/deck/Desktop/FooBar.sh"
Start in: "/home/deck/Desktop

This works, but note the missing double quote at the end (although it doesn't seem to have an effect in practice, i.e. the pwd of the actual process seems correct).

Exec="/home/deck/Desktop/Foo Bar.sh"

This results in
Target: "/home/deck/Desktop/Foo
Start in: "/home/deck/Desktop

This does not work.

The Exec=/path/to/program "/path/to/file" case also doesn't work, the parameter is ignored if it comes with quotes.

See https://github.com/ValveSoftware/steam-for-linux/issues/9237

We have a few more things to check and fix.

fixed in next beta. we ran into a GIO bug (among other things): https://gitlab.gnome.org/GNOME/glib/-/issues/2930

With the 2 Mar 2023 build:

[Desktop Entry]
Type=Application
Name=Foo Bar
Exec="/home/deck/Desktop/Foo Bar.sh" "/tmp/СТИМ ДЕК"

The result is:

Target: "/home/deck/Desktop/Foo Bar.sh"
Start in: /home/deck/Desktop/
Launch options: "/tmp/СТИМ ДЕК"

It seems to work perfectly fine now, thanks!