This PR fixes a crash when GameScope arguments are blank. GameScope commands have to be ended with -- to denote the en of the arguments list. If the user manually edits the GameScope args on the Game Menu and clears them out,
This case is handled correctly by the GameScope GUI, so this only applies to editing the GameScope arguments string on the Game Menu or manually editing the per-game config file.
Problem
With our GameScope args on the main menu, if they are totally empty, we set them to $NON. In our function gameScopeArgs, we give it GAMESCOPE_ARGS (our per-game config string) and then build the GameScope arguments in a format that we can pass as a launch command, split up into an array called GAMESCOPEARGSARR.
However, we only build GAMESCOPEARGSARR if the value we give to gameScopeArgs is not $NON. This means if it is, such as in the case of having an empty GAMESCOPE_ARGS string, we are simply passing nothing. This is a problem, because even if no arguments are given, GameScope commands have to be terminated with --. For SteamTinkerLaunch, blank GameScope arguments means everything after our GameScope binary (i.e. the rest of the launch command, as GameScope usually goes first) is being interpreted by GameScope as a parameter!
In the case of launching Proton games, this would mean our command looks like this: /usr/bin/gamescope /home/gaben/.local/share/Steam/steamapps/common/Proton 8.0/proton --verb=waitforexitandrun -- /path/to/game.exe. The problem here is that there is no -- after the GameScope command, which will cause a crash.
Solution
This PR fixes the above problem by checking if the arguments string given to gameScopeArgs is either $NON or blank (including an empty string like ' ', just an empty string with whitespaces), and if it is, simply set GAMESCOPEARGSARR to have -- and return early. This also removes our nested if logic and flattens the function a little bit.
I tested a game running with Proton 9.0 (Beta) (Cookie Clicker), and a native Linux game (shapez). Both appeared to work fine, and this does not appear to impact defined GameScope arguments, so I am not seeing any regressions.
Fix part of #1048.
Overview
This PR fixes a crash when GameScope arguments are blank. GameScope commands have to be ended with
--to denote the en of the arguments list. If the user manually edits the GameScope args on the Game Menu and clears them out,This case is handled correctly by the GameScope GUI, so this only applies to editing the GameScope arguments string on the Game Menu or manually editing the per-game config file.
Problem
With our GameScope args on the main menu, if they are totally empty, we set them to
$NON. In our functiongameScopeArgs, we give itGAMESCOPE_ARGS(our per-game config string) and then build the GameScope arguments in a format that we can pass as a launch command, split up into an array calledGAMESCOPEARGSARR.However, we only build
GAMESCOPEARGSARRif the value we give togameScopeArgsis not$NON. This means if it is, such as in the case of having an emptyGAMESCOPE_ARGSstring, we are simply passing nothing. This is a problem, because even if no arguments are given, GameScope commands have to be terminated with--. For SteamTinkerLaunch, blank GameScope arguments means everything after our GameScope binary (i.e. the rest of the launch command, as GameScope usually goes first) is being interpreted by GameScope as a parameter!In the case of launching Proton games, this would mean our command looks like this:
/usr/bin/gamescope /home/gaben/.local/share/Steam/steamapps/common/Proton 8.0/proton --verb=waitforexitandrun -- /path/to/game.exe. The problem here is that there is no--after the GameScope command, which will cause a crash.Solution
This PR fixes the above problem by checking if the arguments string given to
gameScopeArgsis either$NONor blank (including an empty string like' ', just an empty string with whitespaces), and if it is, simply setGAMESCOPEARGSARRto have--and return early. This also removes our nestediflogic and flattens the function a little bit.I tested a game running with Proton 9.0 (Beta) (Cookie Clicker), and a native Linux game (shapez). Both appeared to work fine, and this does not appear to impact defined GameScope arguments, so I am not seeing any regressions.
TODO: