Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: gentoo_eshoes@tutanota.com
Newsgroups: gnu.bash.bug
Subject: Re: looking for consistent C-c trap behavior
Date: Sat, 18 Apr 2020 23:41:21 +0200 (CEST)
Lines: 68
Approved: bug-bash@gnu.org
Message-ID: <mailman.629.1587246089.3066.bug-bash@gnu.org>
References: <M58iOBd--3-2@tutanota.com> <a8b7d5fc-0a64-0a0e-bd49-7f808f937813@case.edu> <M5EEHGq--3-2@tutanota.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bug-bash@gnu.org, chet.ramey@case.edu
To: Chet Ramey <chet.ramey@case.edu>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <a8b7d5fc-0a64-0a0e-bd49-7f808f937813@case.edu>
Received-SPF: pass client-ip=81.3.6.162; envelope-from=gentoo_eshoes@tutanota.com; helo=w1.tutanota.de
Precedence: list
Xref: csiph.com gnu.bash.bug:16169




Apr 18, 2020, 22:03 by chet.ramey@case.edu:

> On 4/17/20 3:59 PM, gentoo_eshoes--- via Bug reports for the GNU Bourne
> Again SHell wrote:
>
>> I've noticed that if I trap SIGINT in a bash script, the behavior when e=
ncountering C-c depends on whether an external command (eg. 'sleep 100') or=
 a builtin command (like 'read -p') was encountered.
>>
>
> It's only `read', and it happens when bash is executing in default mode.
>
That's pretty cool that's only 'read', I wrongly assumed(without any prior =
testing) that that applies to any builtin. I still haven't tested, I trust =
you.

> Here's what I wrote (off-list) earlier this month about it; it has come
> up several times before:
>
> =3D=3D=3D=3D=3D
> The idea is that trapping the signal doesn't interrupt the read, kind of
> like a read system call getting restarted if interrupted by a signal and
> reading from the terminal. Since the read doesn't get interrupted, you ha=
ve
> to satisfy it by entering newline. If you didn't have the trap on INT it
> would interrupt the read.
>
> Bash has behaved this way in its default mode for just about forever. In
> posix mode, it interrupts the read system call.
>
can confirm that indeed `bash --posix` does interrupt the 'read -p' on firs=
t C-c, however, the inside-trap seen exit code is 0, but if the trap doesn'=
t `exit` itself, then the exit code after the 'read -p' is seen correctly a=
s 130, ie.
$ ./sigintread.bash=20
Press C-c here...^Cinterrupted sees exit code '0'

Normal exit sees ec=3D130

Would it be possible to somehow get 130 even inside the trap function?

this would then be equivalent with interrupting 'sleep' for example:
$ ./sigintread.bash=20
^Cinterrupted sees exit code '130'

Normal exit sees ec=3D130


On another note, I naively tried to patch out the POSIX requirement, for my=
 own/local_use puposes but had no effect:
in this code
+=C2=A0 /* posix mode SIGINT during read -e. We only get here if SIGINT is =
trapped. */
+=C2=A0 if (posixly_correct && this_shell_builtin =3D=3D read_builtin && si=
g =3D=3D 2)
+=C2=A0=C2=A0=C2=A0 {
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 last_command_exit_value =3D 128|SIGINT;
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 throw_to_top_level ();
+=C2=A0=C2=A0=C2=A0 }
by removing "posixly_correct &&" from above. I've no idea why that would ha=
ve no effect, a bit stumped.I've even tried with a prior 'make clean'. The =
only explanation is that some other code that happens only during `POSIXly =
correct` mode is affecting this somehow...