On 2/6/23 10:26 PM, Martin D Kealey wrote:
By orthogonal, I meant these things should ideally be managed by separate
controls:
1. ignoring signals (or not)
2. redirecting filedescriptors
3. immediately waiting on the process (or not)
4. creating new process groups
5. sending a signal t
On Fri, 3 Feb 2023 at 07:17, Chet Ramey wrote:
> On 1/28/23 5:56 AM, Martin D Kealey wrote:
> > Firstly, let's just leave aside "POSIX requires this" for a bit.
> Be that as it may, POSIX exists and this is a requirement. It's also how
> other shells behave.
>
Of course. I'm only contemplating m
On 1/28/23 5:56 AM, Martin D Kealey wrote:
Firstly, let's just leave aside "POSIX requires this" for a bit. I know
that the requirement is there, and I think it is one of those broken things
that ought to have been dropped from POSIX, or at least reduced to optional
rather than required.
Be
Firstly, let's just leave aside "POSIX requires this" for a bit. I know
that the requirement is there, and I think it is one of those broken things
that ought to have been dropped from POSIX, or at least reduced to optional
rather than required.
On Tue, 24 Jan 2023 at 07:35, Chet Ramey wrote:
>
On 1/21/23 7:55 AM, Tycho Kirchner wrote:
Am 16.01.23 um 18:26 schrieb Chet Ramey:
The fix is to add enough state machinery to detect this situation and
behave in a way that can satisfy both the standard and the later
interpretation, while being careful not to undo this work later. This is
ob
On Sat, Jan 21, 2023 at 01:55:27PM +0100, Tycho Kirchner wrote:
> cmd1 &
> cmd2 &
> wait
>
> If the user having launched this script from the interactive terminal aborts
> it by hitting Ctrl+C, by default, the shell sends SIGINT to the process group
> (pgid) of the script. However, while cmd1 an
Am 16.01.23 um 18:26 schrieb Chet Ramey:
The fix is to add enough state machinery to detect this situation and
behave in a way that can satisfy both the standard and the later
interpretation, while being careful not to undo this work later. This is
obviously not how bash worked in the past.
On 1/12/23 6:34 PM, Tycho Kirchner wrote:
Hi,
we found quite some inconsistency and weirdness in the handling of SIGINT's
during async function calls and were wondering, whether those are expected.
All calls were executed from a script with jobcontrol turned off (set +m)
while pressing Ctrl+C
Date:Fri, 13 Jan 2023 08:29:25 +0100
From:Tycho Kirchner
Message-ID: <6df2fd46-18e8-775d-a670-bd29ffdf3...@mail.de>
| However, did you actually actually put the short snippets into a script,
No, I didn't, and now I have, I see what you mean, bash does look to
be do
Am 13.01.23 um 03:02 schrieb Robert Elz:
Date:Fri, 13 Jan 2023 00:34:02 +0100
From:Tycho Kirchner
Message-ID: <7d59c17d-792e-0ac7-fd86-b3b2e7d4b...@mail.de>
| we found quite some inconsistency and weirdness
| in the handling of SIGINT's during async func
Oh, the differences in what trap -p is printing is because
of special case handling for trap in a subshell environment,
when the trap command is the first (maybe only) command
executed (details vary between shells). That is mostly
intended to allow T=$(trap -p) to work, but is usually applied
to a
Date:Fri, 13 Jan 2023 00:34:02 +0100
From:Tycho Kirchner
Message-ID: <7d59c17d-792e-0ac7-fd86-b3b2e7d4b...@mail.de>
| we found quite some inconsistency and weirdness
| in the handling of SIGINT's during async function calls
Not inconsistent or weird, and has noth
Hi,
we found quite some inconsistency and weirdness in the handling of SIGINT's
during async function calls and were wondering, whether those are expected. All
calls were executed from a script with jobcontrol turned off (set +m) while
pressing Ctrl+C shortly afterwards. In summary:
The main IN
13 matches
Mail list logo
