Games Won't launch (Again)

[NotSoSeriouss]

I know this has already been discussed in #76 and i'm sorry if I had to make this new issue, but i'm having the exact same issue apparently. You can close this issue as duplicate if you want to as long as #76 gets reopened. Sorry for the trouble again

This command: flatpak enter page.kramo.Cartridges flatpak-spawn --host /bin/zsh -c 'xdg-open heroic://launch/legendary/4656facc740742a39e265b026e13d075' Doesn't work, which of course implies that cartridges itself runs into some problems when trying to execute: flatpak-spawn --host /bin/zsh -c 'xdg-open heroic://launch/legendary/4656facc740742a39e265b026e13d075' The output log is the following:

/usr/bin/xdg-open: line 1045: links2: command not found
/usr/bin/xdg-open: line 1045: elinks: command not found
/usr/bin/xdg-open: line 1045: links: command not found
/usr/bin/xdg-open: line 1045: lynx: command not found
TERM is not set
xdg-open: no method available for opening 'heroic://launch/legendary/4656facc740742a39e265b026e13d075'

The log seems to report something about a missing browser but this is insignificant since if I run the command: xdg-open heroic://launch/legendary/4656facc740742a39e265b026e13d075 from the host's terminal, the heroic launcher starts the game correctly without any tweaks needed which is strange

Trying the following command: flatpak enter page.kramo.Cartridges flatpak-spawn --host /bin/zsh -c 'xdg-open --help' outputs:

   xdg-open -- opens a file or URL in the user's preferred
   application

Synopsis

   xdg-open { file | URL }

   xdg-open { --help | --manual | --version }

Use 'man xdg-open' or 'xdg-open --manual' for additional info.

So i'm positive that xdg-open can be reached well from cartridges I have no idea what to do now, plz help?

I am running the latest version of Arch Linux. Cartridges is installed from flatpak and it is at the latest version

[kra-mo]

Do you happen to have /bin/zsh symlinked to /bin/sh? Cartridges runs /bin/sh, not your login shell as it cannot do that from Flatpak.

[kra-mo]

Regardless, this seems to be an issue with the PATH not being correctly set in /bin/sh on your host.

[NotSoSeriouss]

Sorry I wrote the example with /bin/zsh without noticing, but this is the same with /bin/sh since, yes, it is symlinked to /bin/zsh. Also, both /usr/bin and /var/lib/flatpak/exports/bin are in my path

[kra-mo]

Then I'm guessing your PATH gets set in your zshrc and not your zprofile, meaning it only works for interactive non-login shells?

[NotSoSeriouss]

I didn't have a .zprofile file in my home so I made a simple one like this: export PATH="$HOME/bin:$PATH" but it doesn't seem to work. Did I misunderstand your comment? (i'm not very good with env variables and stuff like that)

[kra-mo]

Where is the initial PATH being set? It looks like xdg-open cannot find binaries it needs which are probably not in /home.

[kra-mo]

But if the command doesn't work even when running from the Flatpak shell directly, this is not a Cartridges issue, but rather something with how your shell environment is set up on your host and so I will mark this issue as invalid.

[NotSoSeriouss]

I understand that this is an issue in my system's configuration but still i can't find a solution to this. Should I try to re-install something? What should be present in my PATH for xdg-open to work? I checked 10 times and everything seems to be in place but still it doesn't work

PS: i just tried this: flatpak enter page.kramo.Cartridges /bin/sh -c 'xdg-open steam://rungameid/211820' and it works. I truly have no idea what to do at this point, the issue seems to appear only when flatpak-spawn is used. Also I think it is unnecessary since, after looking at the permissions, cartridges has the filesystem shared with the host already.

[kra-mo]

The issue is not what is set in PATH, but rather when it is set. I don't know where the Arch ZSH package does so, but it seems like it's probably in /etc/zshrc instead of /etc/zprofile so it is only available to non-login shells. I would be curious if you install bash and set that as an alias to your /bin/sh, whether the issue still persists.

[NotSoSeriouss]

I found a fix by changing my path setup thanks