You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way zsh generates its list of recognised signals (signames1.awk -> signames2.awk -> signames.c) isn't ideal:
When zsh can't find the definition for a signal in between the min and the max, it just puts the number in its place. This is useful in some ways — it ensures that subsequent signal numbers aren't affected by the missing ones, and in the event that the signal actually is valid it ensures that we at least recognise the signal by number, even if we don't know the name.
However, it's not useful when the signal is actually undefined. In that case, we have a scenario where zsh thinks a signal exists when it doesn't at all. This is (was) especially noticeable on AIX, which leaves signals 26 and 40 through 59 undefined. In terms of platforms that people actually give a shit about, it isn't currently a problem, but it would be if we addressed the following points.
zsh does not support SIGRT* signals on any platform (except SIGRTMIN on Solaris). That's because...
zsh can not generate signals which are defined in terms of other macros, expressions, or function calls:
// Example from glibc#defineSIGRTMIN __SIGRTMIN
// Example from OpenIndiana#defineSIGRTMIN ((int)_sysconf(_SC_SIGRT_MIN))
I don't see a way around this except to actually compile something from C to evaluate those macros. That'll require a few changes to the signames.c-generation pipe-line.
In order to properly support SIGRT* signals, we'll also need to generate the intervening ones, and we'll need to give them symbolic names. Some systems use names like SIGRTMIN+1 whilst others use SIGRT1. I guess we should probably support both.
(workers/43134 [mentioned])
The way zsh generates its list of recognised signals (
signames1.awk
->signames2.awk
->signames.c
) isn't ideal:When zsh can't find the definition for a signal in between the min and the max, it just puts the number in its place. This is useful in some ways — it ensures that subsequent signal numbers aren't affected by the missing ones, and in the event that the signal actually is valid it ensures that we at least recognise the signal by number, even if we don't know the name.
However, it's not useful when the signal is actually undefined. In that case, we have a scenario where zsh thinks a signal exists when it doesn't at all. This is (was) especially noticeable on AIX, which leaves signals
26
and40
through59
undefined. In terms of platforms that people actually give a shit about, it isn't currently a problem, but it would be if we addressed the following points.zsh does not support
SIGRT*
signals on any platform (exceptSIGRTMIN
on Solaris). That's because...zsh can not generate signals which are defined in terms of other macros, expressions, or function calls:
I don't see a way around this except to actually compile something from C to evaluate those macros. That'll require a few changes to the
signames.c
-generation pipe-line.In order to properly support
SIGRT*
signals, we'll also need to generate the intervening ones, and we'll need to give them symbolic names. Some systems use names likeSIGRTMIN+1
whilst others useSIGRT1
. I guess we should probably support both.References:
The text was updated successfully, but these errors were encountered: