Apr 19, 2020, 21:20 by chet.ra...@case.edu:
> On 4/18/20 6:45 PM, gentoo_esh...@tutanota.com wrote:
>
>>
>>
>> The code that allows 'read -p' to be interrupted when posixly_correct, must
>> then be somewhere else, I shall keep lookin', yet I fear I might not find it
>> :-"
>>
>
> Look in read
On 4/18/20 6:45 PM, gentoo_esh...@tutanota.com wrote:
>
>
>
> Apr 18, 2020, 23:41 by gentoo_esh...@tutanota.com:
>
>>
>> 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
>> + /* posix mode SIGINT during rea
On 4/18/20 5:41 PM, gentoo_esh...@tutanota.com wrote:
> can confirm that indeed `bash --posix` does interrupt the 'read -p' on first
> 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 as
> 130, i
Apr 18, 2020, 23:41 by gentoo_esh...@tutanota.com:
>
> 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
> + /* posix mode SIGINT during read -e. We only get here if SIGINT is
> trapped. */
> + if (posixly_
Apr 18, 2020, 22:03 by chet.ra...@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
>> encountering C-c depends on whether an external command (eg. 'sleep 100') o
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
> encountering C-c depends on whether an external command (eg. 'sleep 100') or
> a builtin command (like 'read -p') was encountered.
Apr 17, 2020, 22:14 by gentoo_esh...@tutanota.com:
>
>
>
> Apr 17, 2020, 22:02 by dual...@gmail.com:
>
>> On Fri, Apr 17, 2020 at 12: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
Apr 17, 2020, 22:14 by gentoo_esh...@tutanota.com:
>
>
>
> Apr 17, 2020, 22:02 by dual...@gmail.com:
>
>> On Fri, Apr 17, 2020 at 12: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 whe
On Fri, Apr 17, 2020 at 1:09 PM Greg Wooledge wrote:
>
> On Fri, Apr 17, 2020 at 01:02:20PM -0700, Eduardo Bustamante wrote:
> > On Fri, Apr 17, 2020 at 12: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 scr
Apr 17, 2020, 22:02 by dual...@gmail.com:
> On Fri, Apr 17, 2020 at 12: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
>> encountering C-c depends on whether an external command (eg.
On Fri, Apr 17, 2020 at 01:02:20PM -0700, Eduardo Bustamante wrote:
> On Fri, Apr 17, 2020 at 12: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
> > encountering C-c depends on whether an
On Fri, Apr 17, 2020 at 12: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
> encountering C-c depends on whether an external command (eg. 'sleep 100') or
> a builtin command (like 'read -p') w
I've noticed that if I trap SIGINT in a bash script, the behavior when
encountering C-c depends on whether an external command (eg. 'sleep 100') or a
builtin command (like 'read -p') was encountered.
I attach an example script which requires me to press C-c twice to interrupt
the builtin 'read
13 matches
Mail list logo
