GMenu2X Revisited (again)

Looks like some of the issues I had with gmenu2x on the zipit have been discovered.  On the zipit IRC channel, dronz pointed out that launching programs with the gmenu2x wrapper setting chewed up memory like it was candy.  Not so good on the zipit with it's stingy 32MB of RAM.  The crappy uclibc versions of the fork and exec functions strike again.  So I created a fix, and rolled a new package along with the updated icons from a while back and some termula2x tweaks.

But what an ugly fix it was...  It turned out the execlp() call in gmenu2x was leaving the huge gmenu2x parent process hanging around, merely suspended and hogging up all the memory, waiting for the child process to die before exiting itself.  You can see it right there in the htop window launched from bash, which was launched from gmenu2x. 

I tried all sorts of clever  trickery with fork and temporary script files, but nothing really worked well until I got frustrated and tried something really stupid.  Running "killall -9 gmenu2x" in the bash shell launched from gmenu2x  did away with the pesky bugger.  So I simply added that to the wrapper script and voila!  It seems to work.  I may fiddle with moving the killall earlier in the wrapper script to free up the memory before the child process, but for now I think it's ok.

You can find the updated package here:

gmenu2x-iz2s.zip 

I still need to fix the launcher code to set the terminal right so emacs stops complaining about /dev/tty and bash no longer whines about not having job control.  The nanonote patch for this doesn't seem to work for me.   But I applied it anyhow, just in case I ever build a z2lite version of gmenu2x.  What does seem to work is running "setsid cttyhack emacs" instead of just emacs in the gmenu2x wrapper settings.  Same for bash.  Oh well, when I finally settle on a permanent solution for this, I'll probably have to do another gmenu2x package update.