On 2011-09-03 15:27:23 +1000, Cam Hutchison wrote: > xpdf's wrapper script should start xpdf.real using 'exec', since it is > the last thing the script does. This means an extra process is not kept > running, and the process will respond properly to signals.
Because of the trap, using exec in the else case is invalid. I've reported another bug about that (but the BTS seems very slow to take it into account... the title is "on a compressed file, xpdf no longer removes the temporary file due to exec"). Though uncompressed files could be treated separately, I don't think it would be a good idea to have a different behavior just for them (in particular because compressed files are more and more common). > Regarding the signal issue, I have a shell script that starts xpdf in > the background and records its PID with $!. When I no longer need xpdf > running, I send a signal to the PID recorded from $! when the process > was launched. Since that PID is actually the wrapper script and not the > real xpdf process, the signals are ignored. Using 'exec' in the script > solves this problem by making the xpdf.real process have the same PID as > the wrapper script. This is the real problem: the xpdf script should trap the signals and propagate them to its child. I don't know how this can be done with /bin/sh (which can be any POSIX shell). With Perl, it would probably be much easier. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
