Fix for zsh signal problems with Slakware

Fix for zsh signal problems with Slakware

[Seth M. LaForge]

Under newer versions of slakware, zsh has the really annoying habit of
totally freezing whenever a child process gets a signal.  I've finally
found the cause.

The problem is that zsh tries to generate signames.h, a list of signal
names, from /usr/include/linux/signal.h.  In recent releases of
slakware, /usr/include/linux/signal.h consists solely of 
#include <asm/signal.h>.  Thus signames.h contains no signal names,
and zsh runs off the end of the signal name array when trying to look
up a signal name.

The solution: change lines 357-360 (in 2.6-beta10) of configure.in
from:

for SIGNAL_H in /usr/include/bsd/sys/signal.h   dnl Next
                /usr/include/linux/signal.h     dnl Linux
                /usr/include/sys/signal.h       dnl Almost everybody else
                /dev/null;                      dnl Just in case we fall through

to:

for SIGNAL_H in /usr/include/bsd/sys/signal.h   dnl Next
                /usr/include/asm/signal.h       dnl Newer Linux
                /usr/include/linux/signal.h     dnl Linux
                /usr/include/sys/signal.h       dnl Almost everybody else
                /dev/null;                      dnl Just in case we fall through

It would be even better to also have configure spit out an error if it
cannot find a signal.h which actually has some signals defined, but
that's a little more work.

This problem is also present in 2.5.03, and the fix should be the
same.

Seth

Re: Fix for zsh signal problems with Slakware

[Richard Coleman]

> Under newer versions of slakware, zsh has the really annoying habit of
> totally freezing whenever a child process gets a signal.  I've finally
> found the cause.
> 
> The problem is that zsh tries to generate signames.h, a list of signal
> names, from /usr/include/linux/signal.h.  In recent releases of
> slakware, /usr/include/linux/signal.h consists solely of 
> #include <asm/signal.h>.  Thus signames.h contains no signal names,
> and zsh runs off the end of the signal name array when trying to look
> up a signal name.

This problem has already been fixed in the baseline zsh sources and will
show up in the next beta release (whenever that is).  I've given up
guessing when that will be.

Richard Coleman
coleman@math.gatech.edu