Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: RedDwarf on September 27, 2007, 10:56:45 am
-
The "xmodmap" is set correctly for the game, but when the game ends isn't restored to the original one. The problem is solved removing the "exec" from 'exec "./fs2_open_r.bin" $*'.
I obtained the script from the Java FreeSpace Open Installer from Turey.
I don't know if the problem is with my system or with the script. Are signal handlers supposed to be maintained after an exec() call? And is the game reprogramming them?
Anyway I think is safer to remove the exec, technically less efficient but...
-
glibc manual (http://www.gnu.org/software/libc/manual/html_node/Initial-Signal-Actions.html#Initial-Signal-Actions) says:
When a new process is created (see Creating a Process), it inherits handling of signals from its parent process. However, when you load a new process image using the exec function (see Executing a File), any signals that you've defined your own handlers for revert to their SIG_DFL handling. (If you think about it a little, this makes sense; the handler functions from the old program are specific to that program, and aren't even present in the address space of the new program image.)
So the script looks clearly incorrect to me. It first sets a handler for different signals with "trap", but then loads a new process image (fs2_open) with "exec".
So I would modify the last part of the script:
# now run this sucker! ...
if [ -x "${FSO_DATA_PATH}/fs2_open.bin" ]
then
cd "${FSO_DATA_PATH}/"
exec "./fs2_open.bin" $*
fi
echo "Couldn't run FreeSpace 2 Open (fs2_open.bin). Is FSO_DATA_PATH set?"
exit 1to
# now run this sucker! ...
if [ ! -x "${FSO_DATA_PATH}/fs2_open.bin" ]
then
echo "Couldn't run FreeSpace 2 Open (fs2_open.bin). Is FSO_DATA_PATH set?"
exit 1
fi
cd "${FSO_DATA_PATH}/"
"./fs2_open.bin" $*