Author Topic: Linux startup script xmodmap trick doesn't works correctly  (Read 2019 times)

0 Members and 1 Guest are viewing this topic.

Linux startup script xmodmap trick doesn't works correctly
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...

 
Re: Linux startup script xmodmap trick doesn't works correctly
glibc manual says:
Quote
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:
Code: [Select]
# 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 1
to
Code: [Select]
# 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" $*
« Last Edit: September 29, 2007, 02:54:04 pm by RedDwarf »