It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
Phacocaster: I don't know the difference between bash and dash....
avatar
eiii: dash is a rather minimal implementation of a bourne shell (sh) and is smaller and faster than bash. That's why it has replaced bash as the default system shell on some distributions. But bash understands more commands. And when the script in an installer uses one of the commands which only bash understands, but wrongly declares /bin/sh instead of /bin/bash for execution, it will fail.
OK, thank you for the explanation (and thanks to @dtgreene too). For the script, i don't really know... Goes to /proc directory and displays the kmem file before exiting ?

But here's the important thing : i've finally managed to install the game, using a weird trick. As said, i have a few installer files because i have downloaded it several times. Each installer has its own crash time. I began the install with one, and when it crashed, i made a copy of every single file installed so when the crashing installer erased them, i could put them back in their directory. Then i run the second installer and told him to never overwrite files. So it installed the files coming after the files installed. Then it crashed, so copy/paste, then run the 1st intaller until it crashes, rinse and repeat until the game's fully installed. And it works !! Had a lot of crashes at the beginning, but setting down the graphics options seemed to make it good.

But it might be the longer install i ever done !
avatar
Phacocaster: OK, thank you for the explanation (and thanks to @dtgreene too). For the script, i don't really know... Goes to /proc directory and displays the kmem file before exiting ?
No, it doesn't actually do that.

You see, the first line of the script is
#!/bin/cat

This line of the script is telling the kernel that the script is to be interpreted by the cat program. Therefore, when you try to execute it (via a command like "./script.sh" after setting the executable bit), the kernel will run the cat program on the script, which will just output the script without executing the commands in it.

So, the actual output of this script, when executed, is the same as the script. Or, in other words, the output is

#!/bin/cat

cd /proc
cat kmem
exit 1
and it will exit successfully (despite the "exit 1" command).

Now, if you instead explicitly run it through the shell (like with "bash script.sh"), then it will try to display the /proc/kmem file, and will likely display an error message before ending in failure.
avatar
dtgreene:
So are you trying to say that using that method we, or preferrably GOG, could force an installer to use bash instead of whatever else happens to come as standard on our distro?

I am pretty lost when it comes to programming.
avatar
dtgreene:
avatar
Themken: So are you trying to say that using that method we, or preferrably GOG, could force an installer to use bash instead of whatever else happens to come as standard on our distro?

I am pretty lost when it comes to programming.
Yes, that can be done with the first line, which is called the shebang. One just needs to put the proper path to the executable.

(Of course, said interpreter needs to exist on the system; if bash is not already installed, a script that specifies bash is not going to work.)

In any case, my example demonstrates that any program can be made to act as the interpreter, though admittedly this is only useful with some programs.
avatar
Phacocaster: But it might be the longer install i ever done !
I'm glad you've managed to install the game. Enjoy it! I still wonder where these installer crashes come from.

avatar
Phacocaster: As said, i have a few installer files because i have downloaded it several times. Each installer has its own crash time.
When you still have these installer files, do their md5 sums differ?
Post edited June 01, 2020 by eiii
avatar
Phacocaster: But it might be the longer install i ever done !
avatar
eiii: I'm glad you've managed to install the game. Enjoy it! I still wonder where these installer crashes come from.

avatar
Phacocaster: As said, i have a few installer files because i have downloaded it several times. Each installer has its own crash time.
avatar
eiii: When you still have these installer files, do their md5 sums differ?
Good idea. They're different... So even if the installer says the archive's ok, it's not necessarily true.
avatar
Phacocaster: They're different... So even if the installer says the archive's ok, it's not necessarily true.
That's bad to hear. But at least it seems to be clear that corrupted installers were causing the problems.
avatar
Phacocaster: They're different... So even if the installer says the archive's ok, it's not necessarily true.
avatar
eiii: That's bad to hear. But at least it seems to be clear that corrupted installers were causing the problems.
It is. I'll try to make the info reach GOG's support.
I accidentally removed my /.local/share/applications/ folder and lost all menu entries for GOG games. Is there easy way to recreate them? I see in /GOG Games/examplegame/support location are some xdg scripts but have no clue what to do with them.
avatar
ssling: I accidentally removed my /.local/share/applications/ folder and lost all menu entries for GOG games. Is there easy way to recreate them? I see in /GOG Games/examplegame/support location are some xdg scripts but have no clue what to do with them.
You can probably write a script that will create them using a template. Most GOG games use the same pattern.
Perhaps someone here can aid me with my current problem.

I'm running Arch Linux and some of my GOG games no longer run. Ronin and Octodad at least. Other games continue to run fine. When running I get the not very common error message:
Illegal instruction (core dumped)

Based on the output of ldd I could track all shared libraries, that are installed. I reinstalled Ronin but the same thing happens. I rebooted (could be a localized RAM corruption issue) but nothing changed. Can anyone please suggest a new course of action? I'm all out of ideas.
avatar
Gede: Illegal instruction (core dumped)
Interesting. Did it run before? What CPU do you have? May be some microcode update affected it?
Post edited June 12, 2020 by shmerl
avatar
Gede: Illegal instruction (core dumped)
avatar
shmerl: Interesting. Did it run before? What CPU do you have? May be some microcode update affected it?
They ran perfectly well. That is what puzzles me. I'll see if I can track down a log of the packages installed since my latest save state.

Your reasoning is quite pertinent. I have an old AMD Athlon(tm) II X2 250 in need of upgrade. But it does what I expect from it. dmesg | grep microcode shows nothing, but I did install a package recently called linux-firmware 20200519.8ba6fa6-1.
Thank you for opening this door for me. I'll see what I can find out.
After another system update, that installed a new kernel and some updated 32-bit libraries, things work well again.
Oh, well, I can't complain. Thanks for the interest.