0

I am trying to run Plarium Play with wine, but have encountered an odd issue. When trying to launch it from a regular desktop entry, I get this JavaScript error:

error 0

This does not happen if I launch from the terminal. If I try and launch it from a desktop entry, even one piping to /dev/null, after first login, without starting Plarium Play from a terminal first, I get two JavaScript errors, one after the other:

error 1 error 2

In both cases, after dismissing them, the splash hangs forever.

This does not happen if I launch Plarium Play from the command line first, then use the modified desktop entry (with an stdio pipe to /dev/null) for later launches. Notably, the program launched from terminal keeps running even if I press Ctrl+C or close the terminal, and later startups with the piped desktop entry are faster than the initial terminal launch, so I assume it is starting a background process. Also notably, if I try to launch Plarium Play after getting the aforementioned launch errors without logging out, it thinks that an instance of Plarium Play is running, and exits immediately.

I cannot launch Plarium Play from the desktop entry, even if I did start the service from the terminal, unless I modify it to at least pipe regular stdio somewhere. If I try with an unmodified desktop entry, I get a similar JavaScript error to the ones above:

error 3

Notably, I can still relaunch Plarium Play after this last error without logging out, so long as I do it from terminal or pipe the output.

My conclusion is that the initial stages of the program to call up an existing instance of the background service NEED to debug somewhere, as do initial stages of the service startup, because of a limitation in JavaScript and Electron (I know little about either). The thing is, the service startup is of course sent to a separate thread, and as such won't use a regular > pipe from the launch command, although it will successfully find a regular terminal's stdio. However, configuring the desktop file to execute in terminal does not fix the problem for some reason. Note that any successful launch whatsoever brings up the Electron GUI of Plarium Play, as it is meant to.

Assuming this conclusion is correct (please tell me if you think it isn't), what can I do to also pipe the attempted stdio access of the server startup thread to /dev/null (or anywhere), so that I do not have to launch Plarium Play from the command line first every time I log in?

TheLabCat
  • 95
  • 10
  • Can't you just `/path/to/application… >/dev/null 2>&1`? This will send both _stdout_ and _stderr_ to `/dev/null`. I suspect that just calling it from a Desktop entry will mean that these two descriptors are closed rather than attached to `/dev/null` – roaima Jul 04 '23 at 15:36
  • Your desktop runtime environment differs from the runtime environment used by `.desktop` files. Look at the results of `echo "=== id ===";id;echo "=== set ===";set;echo "=== env ===";env | sort;echo "=== alias ===";alias` in each of your environments. An easy way is to store the commands in a `bash` script, and execute it from your terminal session, saving the output, then, execute the script from the "other" environment, saving the output. Compare the saved outputs using `diff`. – waltinator Jul 04 '23 at 18:24
  • Can you try adding `Terminal=true` to the desktop file – Nicolas Formichella Jul 04 '23 at 19:13
  • @NicolasFormichella I thought of that too. It didn’t work. – TheLabCat Jul 05 '23 at 16:10
  • @roaima pretty sure I tried that, and it didn’t work. Am currently using ‘binary > /dev/null’ with said effects. Will try the other again. – TheLabCat Jul 05 '23 at 16:11
  • @waltinator I will try that. – TheLabCat Jul 05 '23 at 16:12
  • Please try `screen -md /path/to/application…`, assuming you have `screen` installed – roaima Jul 05 '23 at 19:08
  • @roaima I tried 2>&1, and it actually made the desktop file not work at all. Will try screen... – TheLabCat Jul 06 '23 at 21:16
  • @waltinator That gave me a large file I do not understand. What am I looking for? – TheLabCat Jul 06 '23 at 21:27
  • @roaima the screen command exited immediately with no output or apparent effect. – TheLabCat Jul 06 '23 at 21:49
  • @TheLabCat that's right. It's quite possibly still running with your app. Have you checked (use `screen -ls` to list active sessions)? If there's a session running, use `screen -r {id}` to reattach, where `{id}` can be as little as the first number of a session identifier - eg for `4200.pts-0.localhost` you could use `screen -r 4200` – roaima Jul 06 '23 at 22:00
  • @roaima Hang on, back to your first suggestion, I tried `binary 2>&1 /dev/null`, but that isn't quite what you wrote. Is it what you meant, or should I try again with `binary > /dev/null 2>&1`? – TheLabCat Jul 06 '23 at 23:36
  • @roaima I have no previous experience with the screen command. I'll try again and do that in a moment. – TheLabCat Jul 06 '23 at 23:38
  • Worthy of note, Plarium Play and even Mech Arena are free. – TheLabCat Jul 06 '23 at 23:38
  • @roamia tried it, the session died and disappeared before I could reattach. – TheLabCat Jul 07 '23 at 00:38
  • `binary 2>&1 /dev/null` and `binary >/dev/null 2>&1` are different – roaima Jul 07 '23 at 06:43
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/147089/discussion-between-thelabcat-and-roaima). – TheLabCat Jul 07 '23 at 17:18

1 Answers1

1

When you run a desktop file the file descriptors for stdin (0), stdout (1), and stderr (3) are closed. Your application expects to be able to write (at least) to stdout but because this file descriptor isn't open it causes the program to crash.

The solution is to open the descriptors but redirect them to /dev/null:

application >/dev/null 2>&1

The order is important: first we redirect stdout, and then we redirect descriptor 2 (stderr) to copy descriptor 1 (stdout, now attached to /dev/null)

roaima
  • 107,089
  • 14
  • 139
  • 261