Date:Mon, 6 Apr 2020 15:44:08 -0400
From:Chet Ramey
Message-ID: <20735a7e-627d-763b-adf6-0d94203aa...@case.edu>
| You mean the terminal's input buffer, or readline's line buffer with
| characters it's already read?
As a user I don't distinguish the two cases. A
On 4/6/20 12:00 PM, Robert Elz wrote:
> One other oddity that might be worth documenting, when "read -e" is
> interrupted by a trapped SIGINT, it doesn't flush the input buffer.
> (Without -e the terminal driver does it before anything ever gets received).
You mean the terminal's input buffer, or
Date:Mon, 6 Apr 2020 10:10:47 -0400
From:Chet Ramey
Message-ID: <3e31254d-cc8b-221c-ddb9-ea1ea9fa7...@case.edu>
| I wonder if we're talking about the same thing.
We weren't, but it makes little difference.
| I'm talking about how the
| standard says wait will
On 4/6/20 5:12 AM, Robert Elz wrote:
> Date:Sun, 5 Apr 2020 16:21:53 -0400
> From:Chet Ramey
> Message-ID: <45c766ba-4489-bd7b-40c7-32fed3746...@case.edu>
>
> | That's not how read is defined to behave. wait has special wording
> defining
> | what happens when it
Date:Mon, 6 Apr 2020 15:06:02 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| Or, is it that when job controls are enabled each synchronous command is
| run in its own process group and SIGINT is not sent to the shell at all?
That would be correct.
kre
ps: the
On 4/6/20 8:03 AM, Oğuz wrote:
> Okay, you're right, in posix mode the behavior is as expected. However I
> still didn't get why job controls being enabled/disabled changes the way an
> interactive shell handles signals in posix mode. Like
>
> $ set -o posix
> $
> $ trap 'echo foo' INT
> $
> $ re
Or, is it that when job controls are enabled each synchronous command is
run in its own process group and SIGINT is not sent to the shell at all?
6 Nisan 2020 Pazartesi tarihinde Oğuz yazdı:
> That's not how read is defined to behave. wait has special wording defining
>> what happens when it rec
Date:Sun, 5 Apr 2020 16:21:53 -0400
From:Chet Ramey
Message-ID: <45c766ba-4489-bd7b-40c7-32fed3746...@case.edu>
| That's not how read is defined to behave. wait has special wording defining
| what happens when it receives a signal.
No, it doesn't, that's a misrea
On 4/5/20 5:42 AM, Oğuz wrote:
>> But I see what you mean now, during the read that's called from the
>> trap execution call of foo, SIGINT is blocked - that most probably should
>> not happen, and it looks as if when the trap handler exits, the
>> original read is resumed, that certainly shouldn'
On 4/4/20 1:32 AM, Oğuz wrote:
> While waiting for read builtin to complete, bash executes signal handlers
> in a subshell where signals are ignored.
It doesn't, though. What bash-5.0 does is to effectively block SIGINT
while executing a trap handler for SIGINT, since it doesn't let you run
SIGINT
5 Nisan 2020 Pazar tarihinde Robert Elz yazdı:
> Date:Sun, 5 Apr 2020 05:06:56 +0300
> From:=?UTF-8?B?T8SfdXo=?=
> Message-ID: w...@mail.gmail.com>
>
> | I was expecting it to work (i.e interrupt read again and call foo)
>
> Isn't that what it did?
No, it ignore
Date:Sun, 5 Apr 2020 05:06:56 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| I was expecting it to work (i.e interrupt read again and call foo)
Isn't that what it did?
But I see what you mean now, during the read that's called from the
trap execution call of foo,
Thanks for the reply.
4 Nisan 2020 Cumartesi tarihinde Robert Elz yazdı:
> Date:Sat, 4 Apr 2020 08:32:57 +0300
> From:=?UTF-8?B?T8SfdXo=?=
> Message-ID: mail.gmail.com>
>
> | While waiting for read builtin to complete, bash executes signal
> handlers
> | in a s
Date:Sat, 4 Apr 2020 08:32:57 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| While waiting for read builtin to complete, bash executes signal handlers
| in a subshell where signals are ignored. See below.
|
| $ foo() { trap foo INT; read; }
What that says, i
14 matches
Mail list logo
