Re: PATCH: real-time signals support

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Feb 24, 2024 at 2:01 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> For consistency with ksh and bash, the naming is RTMIN, RTMIN+1 ...
> RTMAX-1, RTMAX. This means that each signal has an alternate name
> so on my system, RTMIN+31 is an alternate name for RTMAX-30.
>
> The patch also adds a -L option to kill similar to bash and ksh which
> prints signals with their numbers as a table.

It looks as if "kill -L" chooses the name with the smallest "absolute value"?

Some suggestions RE -L:
* Drop the right-paren after the signal number, so this output is easily parsed.
* List in columns first rather than across rows.
* Recognize terminal width and change number of columns.
* Print one column (of number-name pairs, obviously) if output is not
a terminal.

I know the "N) NAME" format is bash-reminiscent, but bash also puts
the "SIG" prefix on every name which this already does not.  Anyway
two of those three suggestions are clearly a moderate amount of extra
effort, so just throwing out there.

> On many systems, the
> real-time signals are not numbered contiguously with the earlier
> signals.

Does this mean we should consider making $signals an associative array
like $history?  That would remove the issue that $signals[2] = HUP,
etc., but maybe that's a backward-compat problem.

> Prior to this patch, kill -l uses the WIFSIGNALED and WTERMSIG
> macros to convert a return status to the corresponding signal. But
> zsh simply ORs the status with 0200 (128). So surely we need to
> look for that instead?

Does that mean that Functions/Misc/zargs needs to change the way it
interprets exit status?  There is a presumption that 129+ is "killed
by signal", that 255 is special, and that otherwise 254 is the largest
possible exit status.