http://www.murga.org/~puppy/viewtopic.php?t=10657
the bug not starting if the named pipe file was left on the drive seems to have been fixed, and the bug leaving a pipe file if it was shut down by a kill -3 request seems to have been fixed
my workaround script would not be necessary with the newer Geany, though the script will not cause any problems ... it did nothing unless you tried to start Geany with no instances running, but the pipe file was there
i unzipped the executable from MU's Geany-SVN-Gtk-2.8-international.pup ... i did not "execute" the pup package, and i did not use any other file from the package, just the geany executable ... i put it in my-applications/bin (where it would be out of the way while i tested it) and renamed it to geany9 (to distinguish it from Puppy 2.10's Geany 0.
then i ran it, and looked for it in ps ... but i didn't see the process listed ... until i realized that it was running under the name /root/Choices/MIME-types/text_plain
so the executable was called "text_plain" ... i realized that the reason for this was that geany had replaced Rox's shell script that runs when a text file is clicked, with a symlink to itself ... in this case the symlink was to geany9 in my-applications/bin, because that was where i had put it
i thought this was a bit strange ... oh well, it only seems to do this once, when it first runs ... then it seems to leave the Rox run action script alone ... and you can change the Rox Run Action for a text file by right clicking the file, and it replaces the symlink with the new Run Action script, so it seems ok ... it's just a bit peculiar, that's all
anyway, i wanted to see if Geany would work properly if it was killed gently, and also if it was killed abrubtly ... this is when i found that Busybox's pidof and killall could not find geany ... geany was listed by ps, so you could easily kill it by pid number, but pidof did not see it
Busybox's pidof does have a problem when there is a dir or executable in the working dir with the same name as the executable that it is looking for, but i checked to make sure that was not what was happening
the real, full version of pidof could find the process, but Busybox's pidof couldn't
maybe Busybox is not completely compatible with the kernel's /proc? i remember the older Busybox's top wouldn't work with the 2.6 kernel
anyway, this made me think of rootkits, because rootkits do exactly this kind of thing, hiding their processes from ps etc etc ... i didn't see any signs of rootkit activity, though i really didn't look very hard
Busybox's pidof / killall can see the old Geany
anyway, bottom line: Geany seems to have been fixed, though it seems to deliberately alter Rox's Run Action for text/plain files, and for some reason, pidof and killall can't see the new Geany