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;
}
next prev parent 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).