Add Library Shortcut does not allow spaces in Exec line

[mdeguzis]

For commands with option flags, this makes something such as :

[Desktop Entry]
Name=My Game
Comment=Play this game on Steam
Exec=command --fullscreen --nogui file.iso
Icon=/home/steam/game.png
Terminal=false
Type=Application
Categories=Game;
Name[en_GB]=My Game

....require a script to call the line Exec has. If the Exec= line (and the file as a whole, as known by most) is not "valid," the shortcut will not appear as one that can be added.

[3vi1]

Yep, ran into this one myself and spoke with Prof. K about it in other forums.

But in my experience, you /can/ add some library items from .desktop files that have exec lines with spaces; They will at least sometimes be shown as available to be added as library shortcuts as long as everything before the first space points to a valid executable. But, the created library shortcut will drop everything after the space (and thus not execute correctly). The workaround in that case is to edit the "launch options" for the shortcut to add back all the missing parameters (everything after the first space).

I think the fix for this should be that the parameters automagically get added to the launch options when you create the library shortcut from the steam UI. This creates a working shortcut, and gives easy access to tweak parameters should the need arise.

[3vi1]

Noticed another odd behavior related to the way the Exec line is parsed, and it seems to affect one of the workarounds for the aforementioned problem addressed by this bug report:

For a game I was setting up today, I tried but was unable to workaround the problem mentioned above by putting the actual startup command in a shell script and then putting that script in the Exec line. The new .desktop item just never showed as an option when I went to the SteamOS Add Library Shortcut screen (though the new .desktop file worked fine, and was located in /usr/share/applications, where the steam user would be able to see it.

Changing the target to launch a simple executable caused the shortcut to appear in the Add Library Shortcut screen. Changing it back to point to my shell script (an .sh file owned by steam:steam and located in /home/steam/) caused it to not be available again.

I thought this was really weird, because I had been able to use a script file to work around the Exec problem when adding a World of Warcraft shortcut a few weeks back, and I know Prof. K. had said he had also used it as a workaround in the past.

After trying many things, I found the nonsensical workaround was to move the script file from /home/steam to /home/desktop/bin/ (where I normally keep bin files for the desktop user, and where I just happened to put the WoW file since I had installed it as the desktop user). I also changed the ownership from steam:steam to desktop:desktop and updated the .desktop file accordingly.

At that point SteamOS magically showed the shortcut fine when I went to add it from the Add Library Shortcut screen. The fact that the shortcut worked before, when the script was in /home/steam, but didn't show in the list makes me think that when the list is being built for Add Library Shortcut, that it excludes any targets that are batch files within the steam users directory?

[rpdillon]

This remains an issue. As for @3vi1's issue, I think my experience might shed some light. I had a similar problem adding desktop shortcuts and lost an entire weekend to solving it. I thought I'd mastered it (via shell scripts and desktop files located in /usr/share/applications) after adding five GOG games to my brand new Steam box. Then I tried to add Steamworld Dig from GOG, and the recipe broke. The shell script I was linking to in the desktop file was named steamworld_dig.sh, but SteamOS refused to display it.

After renaming the script in the Exec line to swd.sh, I found SteamOS would cooperate. Given how shortcuts in /home/steam don't work, and the issue with this shortcut, I've concluded that Steam won't read shortcuts that point to an executable that has the word steam in it anywhere (either in the file name itself or in the path).

Many hours of my life died to bring you this information. I hope someone finds it useful.

[wonx]

This is still an issue, at least in Big Picture mode. Programs that launch well from the PC, fail to do so when streaming to my TV when there a space in the path of the executable.