Re: PATCH: real-time signals support

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Tue, Feb 27, 2024 at 11:25 AM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> Bart Schaefer wrote:
> > Some suggestions RE -L:
>
> I'm not especially attached to any particular format here. If you or
> someone else wants to change it I'm not going to object.

I'm not strongly attached either, just used to seeing numbered lists
go down the "page".

> > * Drop the right-paren after the signal number, so this output is easily parsed.
>
> Is parsing kill -L output really that useful?

I was thinking in terms of populating a hash-format of $signals given
that the array-format default is probably not going away.  With the
paren after the numbers I ended up with:

 typeset -A sigs=( ${=${ printf "%d %s\n" ${=${ printf "(%s %s\n"
${=${ kill -L }} }} }} )

Anyway all of these were ideas that popped up as I was reading and
thinking about using the output after applying the patch, keep or
discard as preferred.

> > * List in columns first rather than across rows.
>
> I normally prefer columns first but with the RT signals, I think I
> actually prefer them at the bottom where they're easier to ignore.

Fair enough.

> > * Recognize terminal width and change number of columns.
>
> Ksh also does this. Not entirely to my taste on a wide terminal but I
> usually like my terminal windows narrow and tall anyway.

The main reason is for terminals narrower than 80-ish columns; wider ones, meh.

> > * Print one column (of number-name pairs, obviously) if output is not
> > a terminal.
>
> We don't adjust output for non-terminals from any other builtin.

Also reasonable.  Fixable by asserting a COLUMNS= value if the width
is recognized.

> I couldn't see the point of the "SIG" prefix - adds no information but
> makes it harder to spot particular values.

Exactly; my point was that we're already not a perfect copy of
bash/ksh here, so going further afield is not precluded.

> A greater range of values appear to be open to shell functions but
> otherwise, that sounds about right. There's also negative values.

There would never be a useful negative exit status, would there?
Negative signals translate into the absolute value sent to the process
group leader, right?

% (exit -2)
% echo $?
254