zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh workers <zsh-workers@zsh.org>
Subject: Re: PATCH: real-time signals support
Date: Tue, 27 Feb 2024 20:25:23 +0100	[thread overview]
Message-ID: <14804-1709061923.292710@qlv_.smDE.ovA0> (raw)
In-Reply-To: <CAH+w=7YBrjo=D6Pp9mXh8WQKkrTF0aRR4ddv59bhQjq6bO=Avw@mail.gmail.com>

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;
 	    }


  reply	other threads:[~2024-02-27 19:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-24 22:01 Oliver Kiddle
2024-02-25 22:44 ` Bart Schaefer
2024-02-27 19:25   ` Oliver Kiddle [this message]
2024-02-27 21:12     ` Bart Schaefer
2024-02-27 23:51       ` Oliver Kiddle
2024-02-28  2:17         ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14804-1709061923.292710@qlv_.smDE.ovA0 \
    --to=opk@zsh.org \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).