Re: PATCH: real-time signals support

[Oliver Kiddle <opk@xxxxxxx>]

Bart Schaefer wrote:
> It looks as if "kill -L" chooses the name with the smallest "absolute value"?

Yes. Following the precedent of ksh and bash.

> 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 copied what
bash and ksh do. The patch below handles the two easy suggestions but
I'll wait for confirmation before applying. Is parsing kill -L output
really that useful?

> * Drop the right-paren after the signal number, so this output is easily parsed.
> * 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.

Ksh does this. I suspect they already have a general function for laying
out tables. Perhaps we should factor out the part of print -C which does
this so that it can be reused.

> * 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.

> * 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. This
can be annoying when you want to send the terminal form down a pipeline.

> 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.

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

> 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.

It's probably too late to change. For converting between the two forms,
${ kill -l $sig } is more useful and the array works well enough as a
source for completion. Incidentially, trying to use kill -l in that
manner, it becomes apparent why the `...` and $(...) forms strip
trailing newlines. Given that it aids compatibility with bash/ksh etc
and updating old zsh scripts that use $(...) I'm not too sure that it
preserving newlines is the most helpful behaviour. Parameter flags don't
appear to work with the new form so adding one of those isn't an option.

> 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.

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

Oliver

diff --git a/Src/jobs.c b/Src/jobs.c
index 49decc661..bc9987513 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -2822,23 +2822,25 @@ bin_kill(char *nam, char **argv, UNUSED(Options ops), UNUSED(int func))
 #else
 		const int width = SIGCOUNT >= 100 ? 3 : 2;
 #endif
+		const int cols = isatty(1) ? 5 : 1;
+
 		for (sig = 1; sig < SIGCOUNT
 #if defined(SIGRTMIN) && defined(SIGRTMAX)
 			+ 1
 #endif
 			; sig++)
 		{
-		    printf("%*d) %-10s%c", width, sig, sigs[sig],
-			    sig % 5 ? ' ' : '\n');
+		    printf("%*d %-10s%c", width, sig, sigs[sig],
+			    sig % cols ? ' ' : '\n');
 		}
 #if defined(SIGRTMIN) && defined(SIGRTMAX)
 		for (sig = SIGRTMIN; sig < SIGRTMAX; sig++) {
-		    printf("%*d) %-10s%c", width, sig, rtsigname(sig, 0),
-			    (sig - SIGRTMIN + SIGCOUNT + 1) % 5 ? ' ' : '\n');
+		    printf("%*d %-10s%c", width, sig, rtsigname(sig, 0),
+			    (sig - SIGRTMIN + SIGCOUNT + 1) % cols ? ' ' : '\n');
 		}
-		printf("%*d) RTMAX\n", width, sig);
+		printf("%*d RTMAX\n", width, sig);
 #else
-		printf("%*d) %s\n", width, sig, sigs[sig]);
+		printf("%*d %s\n", width, sig, sigs[sig]);
 #endif
 		return 0;
 	    }